OAuth integrations for MCP become confusing when the MCP server is expected to be everything at once: resource server, login page, token issuer, and client registry. That design may work for one local demo, but it removes the trust boundaries OAuth is giving you basically for free.
A useful reference architecture keeps four roles separate: MCP client, authorization server, access token, and MCP protected resource.
Start at the resource
The MCP client contacts a server and learns its authorization configuration through RFC 9728 protected-resource metadata. The metadata identifies the canonical resource and supported authorization server. The client then uses authorization-server metadata from RFC 8414 to find authorization and token endpoints.
The current MCP specification requires this discovery for HTTP authorization. That matters because the client may encounter servers it was not preconfigured to know. Discovery must still be validated. Metadata is input, not automatic trust.
GET /.well-known/oauth-protected-resource HTTP/1.1
Host: mcp.example.com
{
"resource": "https://mcp.example.com",
"authorization_servers": ["https://identity.example.com"],
"scopes_supported": ["calendar:read", "calendar:write"]
}
Bind the grant to the MCP server
The authorization request should identify the target resource. The resulting access token must be valid for that MCP server only. The server validates issuer, audience, expiry, signature, and scope before processing a protocol request.
Do not use an ID token as the access token. The ID token tells the client about authentication. The access token authorizes the protected resource. Mixing them creates exactly the cross-token confusion that strict audiences and token types are meant to prevent.
Public clients use authorization code with PKCE. Confidential clients authenticate to the token endpoint using an appropriate method. Keep redirect URIs exact and use state to bind the browser response. RFC 9700 collects the current OAuth 2.0 security practices behind these choices.
Scopes describe capabilities, policy limits resources
MCP scopes should be stable capabilities such as calendar:read, not thousands of object identifiers. The MCP server combines scope with tenant, delegated subject, tool arguments, and resource ownership at execution time.
An AI agent calling on behalf of a user may need token exchange from RFC 8693. Exchange the upstream grant for a shorter token with one MCP audience and narrower scopes. Preserve the actor and delegated subject in a form the authorization server and resource understand.
Revocation and audit complete the architecture. The authorization server controls token or grant state. The MCP server records which client and subject called which tool. Sensitive operations can request step-up authentication rather than treating the original login as permanent approval.
The takeaway is not to invent MCP-specific credentials. Use OAuth roles properly. Let the authorization server issue bounded authority and make each MCP server defend its own resource boundary.
Akash Devdhar is a Senior Software Engineer specializing in enterprise identity, authentication, authorization, and AI infrastructure. He writes about building secure AI systems using OAuth, OIDC, RBAC, and modern identity architectures.
Top comments (0)