The MCP authorization specification is short, and most of it points at existing OAuth RFCs. That is a feature: there is very little that is new, and your identity provider almost certainly supports the pieces already. It is also a trap, because "we support OAuth" and "we implement the MCP authorization flow correctly" are not the same claim. Here is what the specification actually requires of a server, in the order a client will hit it.
The roles
The protocol borrows OAuth's vocabulary. Your MCP server is the resource server: it holds the thing the agent wants to use. An authorization server issues tokens. The MCP client (the agent host) is the OAuth client. The specification lets the authorization server be part of your MCP server or a separate system, and in practice it should be separate: your existing identity provider, or a purpose-built service in front of it.
Protected resource metadata
When a client calls your server without a valid token, the server responds with 401 Unauthorized and a WWW-Authenticate header that points at your protected resource metadata document, as defined in RFC 9728. That document is served from a well-known path and lists, among other things, the authorization servers that can issue tokens for this resource and the scopes the resource understands.
This is the step most hand-built servers skip. Without it, every client needs to be manually configured with your authorization server's location, which is exactly the fragile, config-file setup you are trying to escape.
Authorization server discovery
The client reads the metadata, picks an authorization server, and fetches that server's own metadata (RFC 8414, or the OpenID Connect discovery document). That tells it the authorization and token endpoints, supported grant types, PKCE methods, and whether dynamic client registration is offered.
If your identity provider does not publish discovery metadata, or publishes it with gaps, clients will fail here with an error that looks like your server's fault.
Client registration
MCP clients are numerous and you do not control them. The specification therefore says authorization servers should support dynamic client registration (RFC 7591), so a new client can obtain a client ID without a human filling in a form. Where DCR is not supported, the fallback is pre-registered client IDs or a documented manual process, which enterprises sometimes prefer for control.
This is a decision to make deliberately with your security team. DCR is convenient and is what most general-purpose clients expect; pre-registration is what many enterprises want for their own managed agents. Supporting both is common.
PKCE, always
The client runs the OAuth 2.1 authorization code flow. OAuth 2.1 is not a new protocol; it is OAuth 2.0 with the insecure options removed. The consequences for you:
- PKCE is mandatory, for every client, public or confidential. The authorization server must reject requests without it.
- The implicit grant and the resource owner password grant are gone.
- Redirect URIs are matched exactly.
- Refresh tokens for public clients should be rotated or sender-constrained.
Most identity providers support all of this. Make sure the tenant or application you configure for MCP actually enforces PKCE rather than merely permitting it.
Audience-bound tokens
This is the requirement that catches the most teams. The client must include a resource indicator (RFC 8707) in the authorization and token requests, naming your MCP server as the intended audience. The authorization server issues a token whose audience is your server. Your server must then validate the audience and reject any token issued for something else.
The reason is straightforward once you have seen the failure mode. Without audience binding, a token obtained for one service is valid at another, and a malicious or compromised server can collect tokens meant for its neighbors. With it, a stolen token is only useful against the one server it was issued for.
Check that your identity provider honors the resource parameter and emits a matching aud claim. Some do so by default; some need configuration; a few need a bridge.
No token passthrough
Your server validates the token (signature, expiry, audience, scopes) and derives the user's identity from its claims. From here on, every tool call runs as that user.
What your server must not do is send that token onward to your own API or anyone else's. The specification's security guidance is explicit that token passthrough is forbidden. If a downstream call needs credentials, the server obtains its own: a service credential carrying the user's identity, or a token exchange (RFC 8693) that issues a properly scoped downstream token. The identity providers are actively standardizing cross-application access for agents on top of token exchange, and building that seam now means adopting it later is a configuration change.
Scopes and sessions
The specification tells you the mechanism. It leaves several decisions to you, and reviewers ask about all of them:
- Scope design. Coarse scopes (
read,write) are easy to reason about; fine scopes map better to enterprise least-privilege policies. Pick a model and document it in your resource metadata. - Session binding. Streamable HTTP sessions must be tied to the authenticated user, and a session ID must never be accepted as a substitute for a token.
- Token lifetime and refresh. Agent sessions can run for hours. Short access tokens with rotating refresh tokens are the safe default.
- Origin validation. Servers reachable from a browser context must validate the
Originheader to prevent DNS-rebinding attacks.
A checklist
Before you tell a customer your server "supports OAuth", confirm each of these:
- 401 responses carry a
WWW-Authenticatepointer to protected resource metadata - The metadata lists a real authorization server with discoverable metadata
- PKCE is enforced, not just allowed
- Resource indicators are required and the
audclaim is validated on every request - Tokens are never forwarded downstream
- Identity is derived from the token, never from tool arguments
- Scopes are documented and enforced per tool
If any of those is a "not sure", that is the first thing a reviewer will find. It is also the first thing our security audit checks.