Skip to main content
Agent Identity

MCP Steering · 2026-07-28 (current at 1 November 2026 research)

Model Context Protocol — Authorization (HTTP transports)

MCP spec 2026-07-28 /basic/authorization

Related protocolVendor / protocol (not an RFC)AuthorizationAgent-specificField guide

Model Context Protocol — Authorization (HTTP transports) (MCP spec 2026-07-28 /basic/authorization) is Related protocol, 2026-07-28 (current at 1 November 2026 research). This is how most 'ChatGPT/Claude/Cursor calls my tools' auth actually works in 2026: vanilla OAuth 2.1 plus protected resource metadata. It does not give the MCP server an independent agent identity for the model — only a client token for the host.

At a glance

Problem
An MCP client (often an agent host) must access a restricted MCP server on behalf of a resource owner over HTTP, without inventing a proprietary token scheme.
Identity / authn / authz
Authorization at the transport. The MCP server is an OAuth 2.1 resource server; the MCP client is an OAuth 2.1 client. User identity is whatever the AS puts in the token (often via OIDC).

Actors

  • MCP client
  • MCP server (RS)
  • Authorization server
  • Resource owner

How MCP authorization works

Animated sequence · MCP HTTP

MCP HTTP — Who is the OAuth client when a host calls your tools?

The host is the OAuth client

ChatGPT / Claude / Cursor calling your tools: vanilla OAuth 2.1 plus protected resource metadata. PRM is its own hop. Then authorization-code + PKCE as in OAuth 2.1, abbreviated only where the hops are identical. The host is the client. The resource is this MCP server. The model never sees a protocol other than 'call this tool'.

User
MCP host (client)sends
MCP server (RS)gets
Authorization server

Now · 1/14· Discover· MCP authYou are here

MCP host (client)→MCP server (RS)·Unauthenticated HTTP request to the MCP server

The MCP host (OAuth client) calls the MCP server (resource). The model is not the client.

Why The host does not guess the AS. The resource tells it how to authorize. Stdio transports must not use this profile.

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

  • MCP host from the spec
  • MCP server from the spec

Solid = from the spec

Step 1 of 14: host to server. Unauthenticated HTTP request to the MCP server MCP auth
Speed
ShareLinkedInX

MCP 2026-07-28 is an OAuth 2.1 profile, not an RFC. Stdio transports must not use this. Photocopy until you add DPoP. Never forward the pass to another audience. Not AAuth p2p. PRM is a hop of its own.

In one board · MCP HTTP

The host is the OAuth client

ChatGPT / Claude / Cursor calling your tools is this shape: vanilla OAuth plus protected resource metadata. It does not give the model a cryptographic agent identity — only a pass for the host, audience-locked to this MCP server.

  • MCP host

    401 + resource_metadata →

    MCP server
  • User

    Consent (OIDC if you need who) →

    Authorization server
  • AS

    Pass with aud = this server →

    MCP host
  • MCP host

    Authorization: Bearer →

    MCP server
Bearer access tokenresource= canonical MCP URI

Photocopy until you add DPoP. Never put the pass in a query string. Never forward it to a different audience. Not AAuth p2p unless you deliberately leave this profile.

MCP authorization (2026-07-28) is an OAuth 2.1 profile, not an RFC. It still cites an older 2.1 draft — implement token handling against current 2.1 and RFC 9700. Stdio transports must not use this; they take credentials from the environment.

Hop list

Sequence above; this list is the same hops for reading and search. Each row is one message.

  1. 1

    MCP host (client)→MCP server (RS)MCP authUnauthenticated HTTP request to the MCP server

  2. 2

    MCP server (RS)→MCP host (client)RFC 9728401 + WWW-Authenticate resource_metadata URL (RFC 9728 PRM)

  3. 3

    MCP host (client)→MCP server (RS)RFC 9728GET protected resource metadata — this hop is not optional in MCP HTTP

  4. 4

    MCP host (client)→Authorization serverRFC 8414GET authorization-server metadata (RFC 8414)

  5. 5

    MCP host (client)→Authorization serverCIMDRegisters or identifies the host as a client (CIMD preferred; DCR deprecated)

  6. 6

    MCP host (client)→MCP host (client)RFC 7636Generates PKCE code_verifier and S256 code_challenge

  7. 7

    MCP host (client)→Authorization serverOAuth 2.1Authorization request: response_type=code, code_challenge, resource= this MCP URI

  8. 8

    User→Authorization serverOAuth 2.1Authenticates at the authorization server

  9. 9

    User→Authorization serverOIDC CoreConsents. OIDC if the tool needs who — ID Token is not the MCP Bearer

  10. 10

    Authorization server→MCP host (client)OAuth 2.1Redirects back with an authorization code — not an access token in the URL

  11. 11

    MCP host (client)→Authorization serverRFC 7636POSTs the token endpoint: code + code_verifier

  12. 12

    Authorization server→MCP host (client)RFC 8707Returns an access token with aud = this MCP server — not a portable agent identity

  13. 13

    MCP host (client)→MCP server (RS)RFC 6750Authorization: Bearer. Server checks audience == itself

  14. 14

    MCP server (RS)→MCP host (client)RFC 9068Validates aud (RFC 9068 JWT or introspection) and responds

01

The gap for agents

An MCP client (often an agent host) must access a restricted MCP server on behalf of a resource owner over HTTP, without inventing a proprietary token scheme. The 2026-07-28 specification — still the published revision when fetched 1 November 2026 — makes the MCP server an OAuth 2.1 resource server and the MCP client an OAuth 2.1 client.

This is how most 'ChatGPT/Claude/Cursor calls my tools' auth actually works in 2026: vanilla OAuth 2.1 plus protected resource metadata. It does not give the MCP server an independent agent identity for the model — only a client token for the host. Stdio transports SHOULD NOT use this profile; they take credentials from the environment.

02

Actors and trust boundaries

Resource owner authenticates at the AS (often via OIDC). MCP client stores tokens and must not put them in query strings or forward them to other servers. MCP server (RS) must audience-validate: a token minted for another MCP server is an attack. Authorization servers may be third-party; clients MUST support both RFC 8414 and OIDC discovery. Client credentials obtained via DCR or pre-registration MUST be keyed by AS issuer and MUST NOT be reused if PRM points at a new AS.

03

Mechanics

Authorization is OPTIONAL for MCP as a whole. When HTTP authorization is used: (1) AS MUST implement OAuth 2.1 with appropriate security for confidential and public clients. (2) AS and clients SHOULD support CIMD (the spec still cites draft-ietf-oauth-client-id-metadata-document-00; WG draft is -02). (3) DCR MAY, but is deprecated. (4) MCP servers MUST implement RFC 9728; clients MUST use it for AS discovery. (5) AS MUST provide RFC 8414 and/or OIDC Discovery; clients MUST support both. (6) Clients MUST send RFC 8707 resource=<canonical MCP URI> on authorization and token requests regardless of whether the AS honours it. (7) Bearer access tokens per OAuth 2.1 §5; RS MUST validate audience. (8) RFC 9207 iss validation is required in this revision. Protocol-level sessions were removed in 2026-07-28.

Step-up: MCP adds scope-union / hierarchy rules on top of RFC 9470. WWW-Authenticate on 401 carries resource_metadata. CIMD vs DCR selection is specified on the client-registration page.

resource (RFC 8707)from spec
Quoted MCP MUST: canonical MCP server URI on both authorization and token requests, even if the AS ignores it.
Bearer access tokenfrom spec
Quoted: issued for this MCP server as audience. Must not be forwarded elsewhere.
WWW-Authenticate resource_metadatafrom spec
Quoted bootstrap to RFC 9728 PRM.

04

Step-by-step flows

Flow 1

HTTP MCP authorization

  1. 1

    MCP client sends an unauthenticated HTTP request to the MCP server.

  2. 2

    Server 401s with WWW-Authenticate including resource_metadata URL.

  3. 3

    Client fetches RFC 9728 PRM, records resource and authorization_servers.

  4. 4

    Client discovers AS via RFC 8414 and/or OIDC Discovery; verifies issuer.

  5. 5

    Client obtains a client_id: CIMD (SHOULD), pre-registration, or DCR (MAY, deprecated).

  6. 6

    Authorization code + PKCE (OAuth 2.1). resource=canonical MCP URI on authorize and token requests. Validate iss on the response.

  7. 7

    Client calls the MCP server with Authorization: Bearer. Server checks the token was issued for itself. Tokens never go in query strings.

Stdio MUST NOT use this. The model never sees a protocol other than 'call this tool' — the host is the OAuth client.

05

Identity vs authentication vs authorization

Authorization at the transport. User identity is whatever the AS puts in the token (often via OIDC). The MCP server does not learn a cryptographic agent-instance identity unless you add AAuth/WIMSE alongside. Client identity is client_id (CIMD URL or registered).

06

How it composes

07

What bites agent implementers

  • Audience skip

    If the MCP server accepts any token from a popular AS, calendar tokens call payments. Audience check is a MUST.

  • Forwarding tokens

    The host must not pass the MCP access token to third-party APIs. That is confused deputy.

  • Citation lag

    OAuth 2.1-13 and CIMD-00 in the spec text. Implement current drafts/RFCs for token handling; still obey MCP MUST/SHOULD.

  • DCR on an open AS

    Deprecated for a reason. Prefer CIMD. Bind any leftover DCR secrets to the issuer.

  • Tokens in model context

    Bearer tokens plus prompt injection is RFC 6750 theft. Keep tokens in the host, not in the prompt.

08

Stability — what you can ship

Not an RFC. MCP specification revision 2026-07-28 is current as of 1 November 2026. Vendor/protocol stability: the MCP steering process versions independently of the IETF. https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization — ship this profile for HTTP MCP; pin the revision date.

Catalog claims (short form)

Bearer access token
Issued for this MCP server as audience. Must not be forwarded elsewhere.

Implementer notes

Not an RFC. The 2026-07-28 revision still cites OAuth 2.1 draft-13 and CIMD draft-00 — those drafts have moved on. Follow MCP MUST/SHOULD language, but implement token handling against current OAuth 2.1 and RFC 9700. Never put MCP tokens in query strings. Protocol-level sessions were removed in this revision.

Related

Specs

Deployment patterns

Flows

Primary sources