Skip to content
Agent Identity

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

Model Context Protocol — Authorization (HTTP transports)

MCP spec 2026-07-28 /basic/authorization

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

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

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.

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 current when fetched 15 September 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 15 September 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.

Relationship to others

Primary sources