Agent host as OAuth client (MCP HTTP)

DiscoverMCP client→MCP serverMCP auth

Unauthenticated HTTP request

The MCP host (OAuth client) calls the MCP server (resource). Stdio transports must not use this profile.

Why The host does not guess the AS. The resource tells it how to authorize.

Knock on the tool's door with no pass yet.

• MCP host
• MCP server

DiscoverMCP server→MCP clientRFC 9728

401 + WWW-Authenticate resource_metadata URL (RFC 9728 PRM)

WWW-Authenticate points at RFC 9728 PRM. resource = this MCP server, not a portable agent identity.

Why Protected resource metadata is how the client finds the AS and the canonical resource URI. Do not skip this challenge.

The door posts the address of the notice that names the desk.

• WWW-Authenticate
• resource_metadata
• PRM

DiscoverMCP client→MCP serverRFC 9728

GET protected resource metadata — this hop is not optional in MCP HTTP

The host fetches PRM from the URL the 401 advertised. That document names authorization_servers and the resource identifier.

Why Do not fold PRM into the 401. The metadata document is a separate GET.

Read the notice on the tool's door: which desk, which room name.

• protected resource metadata
• authorization_servers
• resource

DiscoverMCP client→Authorization serverRFC 8414

GET authorization-server metadata, then CIMD (preferred) or DCR

The host learns authorization_endpoint and token_endpoint, then gets a client_id at this AS. The model is not the client.

Why Same discovery as OAuth 2.1. CIMD is preferred; DCR is deprecated in MCP 2026-07-28. Optional if the host is already registered.

The host — not the model — takes a number at this desk.

• RFC 8414
• CIMD
• client_id

ProveMCP client→MCP clientRFC 7636

Generates PKCE code_verifier and S256 code_challenge

The host stores a fresh code_verifier. Only the S256 hash will go to the AS.

Why Identical to OAuth 2.1 Prove. Shown so MCP is not a different login.

Drawer secret — same as the OAuth 2.1 hop.

• code_verifier
• S256

GrantMCP client→Authorization serverOAuth 2.1

Authorization request: response_type=code, code_challenge, resource= this MCP URI

The host sends the user-agent to the authorization endpoint. resource= is this MCP server's canonical URI from PRM.

Why Identical grant to OAuth 2.1, plus RFC 8707 resource= bound to this MCP server.

Walk the owner to the desk for a pass to this one tool.

• response_type=code
• PKCE
• resource=

GrantUser→Authorization serverOAuth 2.1

Authenticates at the authorization server

The resource owner authenticates at the AS. The MCP server has not been called with a token yet.

Why Identical to OAuth 2.1. Login is not consent and not the tool call.

The owner shows ID at the pass desk.

• authentication

GrantUser→Authorization serverOIDC Core

Consents. OIDC if the tool needs who — ID Token is not the MCP Bearer

The resource owner consents at the AS. The MCP server will later see an access token, not an ID Token.

Why A human still approves the grant. An ID Token, if issued, stays with the host.

The owner signs the slip for this tool, not a nametag for the API.

• consent
• ID Token

GrantAuthorization server→MCP clientOAuth 2.1

Redirects back with an authorization code — not an access token in the URL

The host receives a code. The MCP Bearer is not in this hop.

Why Identical to OAuth 2.1. MCP does not revive implicit.

A ticket for this tool's desk.

• code
• no implicit

GrantMCP client→Authorization serverRFC 7636

POSTs the token endpoint: code + code_verifier

grant_type=authorization_code, code, code_verifier. Prefer DPoP on this POST if you can.

Why Identical to OAuth 2.1 back-channel redemption.

Cash the ticket with the drawer secret.

• token endpoint
• code
• code_verifier

GrantAuthorization server→MCP clientRFC 8707

Returns an access token with aud = this MCP server

The token endpoint returns an access token to the host. The model never sees it.

Why Audience is this resource. Forwarding the pass to another MCP server is a mix-up. Still a Bearer photocopy until you add DPoP.

A pass for this door, held by the host.

• access token
• aud
• Bearer

CallMCP client→MCP serverRFC 6750

Authorization: Bearer. Server checks audience == itself and responds

The host calls this MCP server with the access token in the Authorization header. Do not forward it to another server. The server validates aud (RFC 9068 JWT or introspection).

Why Audience validation is the difference between a calendar token and a payments incident. Not AAuth signed HTTP. Not an Agent Card.

Show the pass at this tool's door. Do not photocopy it to the next tool.

• Authorization: Bearer
• aud
• RFC 9068