The Model Context Protocol's authorization specification, finalized in November 2025, defines exactly how an MCP client obtains and uses credentials for an HTTP-based MCP server: OAuth 2.1 with PKCE mandatory on authorization-code flows, RFC 8707 resource indicators on token requests, and protected-resource metadata for discovery. As of July 2026, this is the interoperability baseline — spec-compliant clients expect this flow, and servers that implement authorization any other way are opting out of the ecosystem.

This post walks the flow step by step, explaining what each moving part does and which attack it exists to prevent. If you want the strategic comparison against static credentials instead, see MCP server authentication: OAuth 2.1 vs API keys; for the full security surface beyond authentication, see securing MCP servers.

The cast of characters

Four parties participate in MCP authorization:

  • The MCP client — the agent, IDE, or application that wants to call tools. In OAuth terms, the client.
  • The MCP server — the tool provider. In OAuth terms, the protected resource. Note what it is not: the MCP server is not the authorization server, and the spec explicitly separates the two roles.
  • The authorization server (AS) — the system that authenticates clients (and users, where flows are user-delegated), and mints tokens. May be your IdP, a cloud provider's OAuth service, or a dedicated service.
  • The resource owner — for user-delegated flows, the human whose authority the client exercises; for machine-to-machine flows, effectively the organization.

The design goal threading the whole spec: a client that has never seen a given MCP server before can discover how to authenticate to it, obtain an appropriately-scoped token, and call it — with no out-of-band configuration and no secrets shipped in config files.

Step 1: Discovery via protected-resource metadata

The flow begins when a client calls an MCP server without a valid token and receives 401 Unauthorized — along with a pointer to the server's protected-resource metadata (per RFC 9728). That metadata document declares, machine-readably: which authorization server(s) protect this resource, what scopes it uses, and the resource identifier the client must use in token requests.

What this kills: configuration-based trust mistakes. Before standardized discovery, clients were configured by hand with token endpoints and audiences — and misconfiguration (pointing at the wrong AS, reusing another server's audience) was both common and silently dangerous. Discovery makes the server itself the authoritative source for how to authenticate to it.

Step 2: Client registration

The client registers with the discovered authorization server — often via dynamic client registration, so unattended clients can onboard without a human creating OAuth apps by hand. Registration yields a client identity: a client_id, plus a secret or key for confidential clients.

What this kills: anonymous callers. Every subsequent token is traceable to a registered client identity, which is what makes per-client revocation, rate limiting, and audit attribution possible at the AS.

Step 3: The PKCE-protected authorization

For user-delegated access, the client runs the OAuth 2.1 authorization-code flow — and the MCP spec makes PKCE (Proof Key for Code Exchange) mandatory, for confidential clients as well as public ones.

PKCE works in three moves: the client generates a random secret (the code verifier) and sends a hash of it (the code challenge) with the authorization request; the AS remembers the challenge and issues an authorization code; when the client exchanges the code for tokens, it must present the original verifier, which the AS hashes and compares. The verifier never travels until the final, TLS-protected token request.

What this kills: authorization-code interception and injection. An attacker who steals the authorization code — via redirect manipulation, logs, or a malicious app registered on the same redirect scheme — cannot redeem it without the verifier. Making PKCE universal (rather than public-clients-only, as in OAuth 2.0 practice) also eliminates a class of downgrade and misconfiguration bugs where confidential clients skipped it.

For pure machine-to-machine access — an autonomous agent with no user in the loop — the client credentials grant applies instead, with the client authenticating directly to the token endpoint. The agent authentication guide covers when each grant fits.

Step 4: The resource-bound token request

Whichever grant is used, the MCP spec requires the token request to carry an RFC 8707 resource indicator: a resource parameter naming the specific MCP server (the identifier from its metadata) the token is intended for. The AS mints an access token whose audience is that server — and only that server.

What this kills: token replay and the confused deputy. Without audience binding, a token accepted by one server is often accepted by others trusting the same AS — so an agent (or attacker) holding a token for a harmless server can replay it against a sensitive one. With audience binding, the sensitive server rejects the token on sight: wrong audience, no access, regardless of how the caller obtained it. This is the property that holds even when the agent itself is manipulated — a prompt-injected agent cannot be tricked into using its document-search token against the payments server, because the payments server will not take it.

Step 5: Presentation and verification

The client calls the MCP server with the access token. The server verifies: signature and issuer (is this from an AS I trust — per my own metadata?), expiry (tokens should live minutes-to-an-hour), audience (is this token for me? — the check that makes step 4 real), and scopes (does the token authorize this operation class?).

Two server-side disciplines complete the picture. First, no token passthrough: the MCP server must not forward the client's token to downstream APIs — it authenticates downstream with its own credentials, keeping each trust relationship explicit. Second, token verification establishes who is calling; it does not decide what they may do with each tool — tool-level allow-lists, parameter guardrails, and rate limits are a separate enforcement layer above authentication, which is where a governance platform earns its place (see registering and governing MCP servers).

The flow at a glance

  1. Client calls server → 401 + protected-resource metadata (RFC 9728).
  2. Client discovers and registers with the authorization server.
  3. Client runs OAuth 2.1: authorization code + PKCE (user-delegated) or client credentials (M2M).
  4. Token request includes resource (RFC 8707) → AS mints a short-lived, scoped, audience-bound token.
  5. Client presents token; server verifies issuer, expiry, audience, scope — then applies its own tool-level authorization.

Each element earns its complexity by killing an attack class: discovery kills misconfiguration, registration kills anonymity, PKCE kills code interception, resource indicators kill replay and confused deputies, short lifetimes kill long-tail credential leakage.

Common questions

What did the November 2025 MCP authorization spec make mandatory? For HTTP-based MCP servers implementing authorization: OAuth 2.1 with PKCE required on authorization-code flows (including for confidential clients), RFC 8707 resource indicators on token requests, and protected-resource metadata so clients can discover the responsible authorization server. As of July 2026 this is the current baseline for spec-compliant implementations.

What does PKCE actually protect against? Interception and injection of the authorization code. The code alone becomes worthless: redeeming it requires the code verifier, a secret that never leaves the client until the final token request. PKCE costs one random string and one hash per flow.

What is an RFC 8707 resource indicator? A resource parameter in the token request naming the specific server the token is for. The authorization server mints the token audience-bound to that server, and every other server rejects it — closing token replay and confused-deputy attacks structurally rather than behaviorally.

Does my MCP server need to be its own authorization server? No — the spec deliberately separates the roles. Your server publishes metadata pointing at the AS that protects it (your IdP or OAuth service) and verifies the tokens that AS mints. Building token issuance into every MCP server is exactly what the architecture avoids.

Is authentication enough to make an MCP server safe to expose? No. The flow above establishes verified identity and audience-bound access — the foundation. What the caller may do per tool, at what rate, with what content flowing through, is a governance layer on top: tool scoping, guardrails, and audit, covered in the MCP server security checklist.