[EAAPL-MCP004] MCP Authentication & Authorisation

Category: MCP Sub-category: Security Version: 1.0 Maturity: Emerging Tags: mcp, authentication, authorisation, oauth2, mtls, rbac, scopes, token-validation, zero-trust Regulatory Relevance: EU AI Act Art. 9/15, APRA CPS 234, ISO/IEC 42001 §8.4, NIST AI RMF (GOVERN 1.1, GOVERN 1.6), Privacy Act 1988 (Cth)

1. Executive Summary

The MCP Authentication & Authorisation Pattern defines the identity, authentication, and authorisation architecture for securing MCP server access. It covers three distinct authentication contexts: human users authorising AI actions on their behalf (OAuth 2.1 with PKCE), machine-to-machine server connections (mTLS or OAuth 2.1 client credentials), and AI agents acting with delegated identity (scoped bearer tokens with capability-bound claims). The pattern defines how capability-level access control is expressed, enforced, and audited — ensuring that every MCP tool and resource invocation is tied to an authenticated, authorised identity with the minimum capability set required for its function.

For CIO/CTO audiences: authentication and authorisation are not optional additions to an MCP deployment — they are the mechanism by which your organisation maintains control over what AI systems can do. Without them, any process that can reach your MCP server can invoke any tool and read any resource. The MCP Auth & Authz pattern is the enterprise answer to the question "who is allowed to do what with our AI integration layer, and how do we prove it?" It maps to the same identity governance frameworks your organisation already operates — OAuth 2.1, RBAC, privileged access management — applied to the novel context of AI model-to-system interactions.

2. Problem Statement

Business Problem

AI systems are being granted access to enterprise systems without applying the identity governance controls that would be mandatory for human users. An MCP server handling customer financial data with no authentication is the equivalent of an internal API endpoint accessible without credentials — a risk no organisation would accept for human users, but one that routinely appears in early AI deployments. The absence of authorisation controls means there is no mechanism to enforce least-privilege access, and no way to revoke an AI system's access to specific capabilities independently of shutting it down entirely.

Technical Problem

The MCP protocol specifies the wire format for tool invocation and resource access but delegates authentication and authorisation to the deployment layer. Without a defined auth architecture, implementers apply inconsistent approaches: API keys embedded in configuration files, shared service accounts with no capability scoping, or no authentication at all for internal deployments. There is no standard for expressing capability-level permissions as first-class claims in an identity token, and no defined mechanism for an AI agent to acquire delegated authority from a human user at runtime.

Symptoms of Absence

• MCP servers accept connections from any client that can reach the network endpoint, with no identity verification
• All tool invocations are attributed to a generic "service account" with no per-agent or per-session granularity
• There is no way to revoke a specific AI agent's access to a specific tool without rebuilding the server's configuration
• Tool invocation audit logs contain no authenticated identity — only IP address and tool name
• An AI agent can invoke tools with higher privilege than required for its current task, with no technical enforcement of least-privilege

Cost of Inaction

• Security: Unauthenticated MCP servers are accessible to any internal threat actor; unscoped service accounts enable lateral movement via tool invocations
• Compliance: Tool invocation audit logs without authenticated identity attribution are materially insufficient for APRA CPS 234 and Privacy Act breach investigation requirements
• Operational: No capability-level revocation means the only response to a compromised AI agent is complete service shutdown
• Governance: Cannot demonstrate to regulators or auditors that AI system access to enterprise systems is governed by the same identity controls as human access

3. Context

When to Apply

• Any MCP server that accesses enterprise systems, internal data, or user data — which is to say, any production MCP server
• AI agents that act on behalf of human users (delegated authority requires the user-consent OAuth 2.1 flow)
• Multi-tenant deployments where different clients or teams must be isolated from each other's capabilities
• Regulatory environments requiring demonstrable access controls over AI system interactions with sensitive data
• Any MCP server accessible over a network (as opposed to a local stdio server used only by a fully trusted local process)

When NOT to Apply

• Local stdio MCP servers used exclusively within a single trusted developer process with no network exposure and no sensitive data access — auth overhead exceeds benefit
• Proof-of-concept deployments with entirely synthetic data and no production system access; add auth before any real data is involved
• Cases where the calling context is already authenticated at a lower layer (e.g., an mTLS service mesh where both parties are mutually authenticated at the network layer) and the MCP server can rely on network-layer identity assertions

Prerequisites

• An enterprise identity provider (IdP) capable of issuing OAuth 2.1 tokens with custom claims (Entra ID, Okta, Keycloak, Auth0, Cognito)
• Certificate authority (internal or managed) for mTLS client certificate issuance for machine-to-machine flows
• Secrets management infrastructure for storing client credentials and rotating them automatically
• The capability register (EAAPL-MCP001) which defines the access tier required for each tool and resource — authorisation cannot be implemented without knowing what it is protecting

Industry Applicability

4. Architecture Overview

MCP authentication and authorisation operates across three distinct flows, each requiring a different approach to identity establishment and capability verification.

User-delegated flow (OAuth 2.1 with PKCE): When an AI agent acts on behalf of a human user, the user must explicitly consent to the specific capabilities the agent will exercise. This flow follows the OAuth 2.1 authorisation code grant with PKCE: the MCP client redirects the user to the authorisation server, the user authenticates and consents to the requested tool scopes, and the authorisation server issues an access token with the consented capability claims. The MCP server validates the token on every request and enforces that the invoked tool is within the token's declared scope. This flow provides non-repudiation: each tool invocation is attributable to a specific human user who explicitly consented to the action.

Machine-to-machine flow (OAuth 2.1 client credentials or mTLS): When an AI agent acts autonomously without a live human user in the loop, the agent authenticates using a client credential — either an OAuth 2.1 client credentials grant (issuing a short-lived bearer token) or a mutual TLS client certificate. The client identity is registered in the authorisation server with a fixed set of permitted capability scopes; the agent cannot acquire scopes beyond those registered. Client credentials must be stored in a secrets manager and rotated on a defined schedule (90 days maximum for bearer credentials; annually for mTLS certificates).

Capability-scoped authorisation model: Regardless of authentication flow, authorisation is enforced at the capability level — not at the server level. Each tool and resource in the capability register is assigned a required scope string (e.g., mcp:tools:database:read, mcp:tools:email:send). Bearer tokens and mTLS certificates carry a set of granted scopes. The MCP server's authorisation middleware checks that the authenticated identity's token contains the required scope for the invoked capability before executing the handler. This model enables fine-grained revocation: removing a single scope from a client's registration revokes access to all tools requiring that scope without touching any other access.

Wire Protocol Detail

Authentication state in MCP is carried at two levels: the transport layer (HTTP Authorization header or mTLS handshake) and the MCP protocol layer (the initialize request can carry identity metadata via _meta). The following examples show the exact wire format for each authentication context.

OAuth 2.1 bearer token — HTTP transport (Streamable HTTP / SSE):

POST /mcp HTTP/1.1
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{"tools":{}},"clientInfo":{"name":"agent-crm-writer","version":"1.0"}}}

The server validates the JWT before processing the JSON-RPC body. If the token is invalid or expired, the server returns HTTP 401 with a WWW-Authenticate header — not a JSON-RPC error, because the MCP session has not been established yet:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="mcp-server",error="invalid_token",error_description="Token expired"

Scope enforcement at tool invocation — after initialize succeeds, the server checks the token's scope claim on every tools/call. A scope violation returns a JSON-RPC application error (HTTP 200, JSON-RPC error body):

// tools/call with insufficient scope
{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"update_customer","arguments":{"customer_id":"AU-98432","status":"inactive"}}}

// scope violation response (JSON-RPC -32000 application error, not HTTP 403)
{"jsonrpc":"2.0","id":3,"error":{"code":-32000,"message":"Insufficient scope","data":{"required":"mcp:crm:customers:write","granted":["mcp:crm:customers:read"],"tool":"update_customer","identity":"agent-crm-writer@domain.com"}}}

Machine-to-machine — OAuth 2.1 client credentials token request (occurs before the MCP session):

POST /oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=mcp-agent-loan-processor
&client_secret=<retrieved-from-secrets-manager>
&scope=mcp%3Acrm%3Acontacts%3Aread+mcp%3Adatabase%3Aorders%3Aread

// Token response (short-lived, 60-minute maximum for write-capable scopes)
{"access_token":"eyJhbGci...","token_type":"Bearer","expires_in":3600,"scope":"mcp:crm:contacts:read mcp:database:orders:read"}

Capability-level scope claim in a decoded JWT — showing the exact structure the server's authorisation middleware parses:

{
  "sub": "mcp-agent-loan-processor",
  "iss": "https://auth.example.com.au",
  "aud": "https://mcp-server.internal",
  "iat": 1718323200,
  "exp": 1718326800,
  "scope": "mcp:crm:contacts:read mcp:database:orders:read",
  "client_id": "mcp-agent-loan-processor",
  "tenant_id": "au-east-prod"
}

The server's scope validator splits the scope claim string on spaces, then checks whether the required scope for the invoked tool is in the resulting set. The scope check is O(1) with a set lookup — not a regex or substring match, which would allow mcp:crm:contacts:read:admin to falsely match mcp:crm:contacts:read.

5. Architecture Diagram

6. Components

7. Implementation Steps

Step 1: Define the Capability Scope Model

Before implementing any authentication code, define the full scope namespace for your MCP deployment. Assign a unique, hierarchical scope string to every tool and resource in the capability register: use the pattern mcp:<server-id>:<capability-type>:<action> (e.g., mcp:crm:contacts:read, mcp:crm:contacts:write, mcp:database:orders:read). Group scopes into logical roles (e.g., a crm-read-only role includes all mcp:crm:*:read scopes). Register these scopes in the authorisation server as a named resource server. This scope model is the governance document that defines the capability boundary of the entire MCP deployment.

Step 2: Implement the User-Delegated OAuth 2.1 Flow

For MCP clients that act on behalf of human users, implement the OAuth 2.1 authorisation code grant with PKCE. The client must display the list of requested capability scopes to the user in human-readable form before the consent screen — "This AI assistant will be able to read your email and create calendar events on your behalf." Configure the authorisation server to require explicit user consent for AI-specific scopes (not just profile and email). Issue short-lived access tokens (15–60 minutes) with refresh token rotation. The MCP server must validate the token's scope claim against the required scope for each tool invocation — not just the token's validity.

Step 3: Implement the Machine-to-Machine Credential Flow

For autonomous AI agents, register a service client in the authorisation server with a precisely scoped set of permitted capabilities. Use the OAuth 2.1 client credentials grant to issue short-lived bearer tokens (maximum 1-hour TTL). Store the client secret in the secrets manager — never in environment variables or configuration files. Implement automatic secret rotation in the secrets manager: the MCP client retrieves the current secret at token request time, not at startup. For higher-assurance deployments, replace client secret with mTLS: issue a short-lived client certificate via the internal CA, and configure the MCP server to validate the certificate and extract the client identity from the certificate's Subject Alternative Name.

Step 4: Implement Authorisation Enforcement in the Server

Add authorisation middleware to the MCP server that fires after token validation and before capability routing. The middleware extracts the granted scopes from the validated token and compares them against the required scope for the invoked tool or resource (looked up from the capability scope registry). On scope mismatch, return a JSON-RPC application error with a structured INSUFFICIENT_SCOPE error code — do not return a generic 403 that reveals nothing about which scope is missing. Log every authorisation decision (permit and deny) with the client identity, requested capability, required scope, and granted scopes to the auth audit log.

AU Compliance Note — APRA CPS 234 Attachment C & APS 330: Authentication and authorisation controls are the primary subject of APRA CPS 234 Attachment C testing. "Testing the effectiveness of information security controls" for an MCP deployment means demonstrating that: (1) every tool invocation is attributable to an authenticated identity (not just an IP address); (2) the scope enforcement cannot be bypassed — including by a compromised AI agent attempting to invoke tools outside its registered scope; (3) revocation is effective within the token TTL window. Auth audit logs must record every authorisation decision — both permits and denies — with the full identity, scope, and tool context. These logs, retained for 7 years per APS 330, are the primary evidence for Attachment C testing. APRA has signalled in its CPS 234 guidance that access controls for systems interacting with "sensitive information assets" (which includes customer financial data accessible via MCP tools) must be equivalent in rigour to those applied to human administrators. A shared service account with no scope differentiation does not satisfy this standard; per-agent client registrations with per-tool scopes do.

8. Security Considerations

OWASP LLM Top 10 Mapping

Additional Controls

• Implement token binding where the transport layer supports it — ties the access token to the specific TLS session, preventing token theft and replay
• Enforce a maximum token TTL of 60 minutes for any token that grants write-capable tool scopes; require re-authentication for long-running sessions
• Implement OCSP stapling and short certificate lifetimes (24–72 hours) for mTLS deployments to ensure rapid revocation propagation
• Audit all client registrations quarterly: review the scope set granted to each registered AI agent identity and remove scopes no longer required
• Implement an emergency revocation endpoint in the authorisation server that immediately invalidates all tokens issued to a specific client identity — activate during compromise incidents

9. Governance Artefacts

• Capability Scope Register — complete mapping of every MCP tool and resource to its required OAuth 2.1 scope string; owned by the MCP platform team; reviewed quarterly
• Client Registration Inventory — list of all registered AI agent client identities with their granted scope sets, credential type, rotation schedule, and business owner
• User Consent Records — OAuth 2.1 consent grants issued to AI agents acting on behalf of users; retained per Privacy Act requirements
• Auth Audit Log — immutable record of all authentication events and authorisation decisions; retained per APRA CPS 234 (7 years for financial services)
• Credential Rotation Log — record of every client secret or certificate rotation, including rotation date, method, and confirmatory test result

10. SLOs

11. Cost Model

12. Trade-off Analysis

13. Failure Modes

14. Regulatory Mapping

15. Reference Implementations

AWS

Use Amazon Cognito as the OAuth 2.1 authorisation server, with a User Pool for user-delegated flows and a machine client in the App Client configuration for M2M client credentials. Define custom scopes in the Cognito resource server for each MCP tool category. Use AWS Secrets Manager with automatic rotation for client secrets. Validate JWT tokens locally using Cognito's JWKS endpoint — cache the JWKS with a 1-hour TTL and refresh on key ID mismatch. Use AWS Private CA for mTLS certificate issuance for high-assurance M2M flows.

Azure

Use Microsoft Entra ID (formerly Azure AD) as the authorisation server. Register the MCP server as an App Registration with a defined set of Application Permissions (for M2M) and Delegated Permissions (for user-delegated flows). Use Entra ID's OAuth 2.1 implementation natively — it supports PKCE and custom scopes out of the box. Store client secrets in Azure Key Vault with automatic rotation. Validate tokens locally using the Entra ID JWKS endpoint. Use Entra Certificate-Based Authentication for mTLS in high-assurance deployments.

On-Premises / Self-Hosted

Deploy Keycloak as the authorisation server. Define a dedicated Keycloak Realm for MCP deployments with realm-level client registrations for each AI agent identity. Use Keycloak's fine-grained authorisation (UMA 2.0) to model capability-level permission policies. Integrate Keycloak with HashiCorp Vault for client secret management — Vault generates Keycloak client secrets and stores them; rotation is automated via Vault dynamic secrets. Use cert-manager on Kubernetes for automated certificate lifecycle management in mTLS deployments.

16. Related Patterns

• EAAPL-MCP001: MCP Server Design — the server that auth middleware is implemented within
• EAAPL-MCP002: MCP Gateway — gateway is the preferred enforcement point for authentication across the MCP fleet
• EAAPL-MCP005: Stateful MCP Sessions — session token management for long-running authenticated MCP sessions
• EAAPL-AGT009: Agent Identity & Authorisation — parent pattern covering AI agent identity for non-MCP contexts
• EAAPL-SEC003: Zero-Trust Architecture — the broader zero-trust framework within which MCP auth operates

17. Maturity Assessment

18. Revision History