Beyond the flows

OAuth in the AI era

Last reviewed: 28 September 2026. This area moves quickly, so check the linked sources for the latest.

How MCP uses OAuth

The Model Context Protocol (MCP) lets an AI app connect to tools and data on a server. For remote servers, its authorization rules are built on OAuth. The MCP server acts as the resource server, and the AI app is the client.

1. 01Discovery. The MCP server publishes Protected Resource Metadata (RFC 9728) naming its authorization server. The client then reads that server's metadata (RFC 8414).
2. 02Client identity. The client is known by a Client ID Metadata Document (a URL), a pre-registered ID, or Dynamic Client Registration (RFC 7591) as a fallback.
3. 03Authorization. The standard Authorization Code flow with PKCE, as in OAuth 2.1.
4. 04Audience. The client sends a resource parameter (RFC 8707), and the server must reject tokens that were not issued for it.

The rules changed between MCP versions. The 2025-11-25 version made Client ID Metadata Documents the recommended way to identify a client. The 2026-07-28 version deprecates Dynamic Client Registration (it still works for now), adds issuer checking (RFC 9207) and clarifies scope step-up. The release announcement has the summary. MCP is a spec still changing, so read the current version.

Published standards

These are finished and stable.

• RFC 8414RFC

  Authorization Server Metadata: a well-known document that describes an authorization server.

• RFC 9728RFC

  Protected Resource Metadata: a resource server (like an MCP server) says which authorization server to use.

• RFC 7591RFC

  Dynamic Client Registration: a client registers itself with an authorization server on the fly.

• RFC 8707RFC

  Resource Indicators: the client says which server a token is for.

• RFC 8693RFC

  Token Exchange: swap one token for another, including one that says "acting on behalf of".

• RFC 9449RFC

  DPoP: ties a token to a key held by the client, so a stolen token is harder to use.

• RFC 9396RFC

  Rich Authorization Requests: ask for precise permissions, not just a scope string.

• CIBA Core 1.0Final spec

  Client-Initiated Backchannel Authentication: ask a user to approve on another device, with no browser redirect.

  OpenID Foundation, not IETF

Drafts still in progress

An Internet-Draft is work in progress. It can change or never be published, so do not treat it as a standard.

• OAuth 2.1Internet-Draft

  Rolls the current best practice (PKCE, no implicit flow) into one document.

  draft-ietf-oauth-v2-1, version 15 at last check

• Client ID Metadata DocumentInternet-Draft

  A URL is the client ID, and it points to a document describing the client.

  OAuth WG draft

• Transaction TokensInternet-Draft

  Carry user and workload identity through a chain of internal calls.

  version 08 at last check

• Identity and Authorization ChainingInternet-Draft

  Keep identity and authorization when a request crosses trust domains.

  approved by the IESG, not yet an RFC at last check

• Identity Assertion JWT Authorization GrantInternet-Draft

  A company identity provider vouches for a user, so an app can get access without another consent screen.

  version 04 at last check; used by MCP enterprise-managed authorization

• On-Behalf-Of for AI agentsInternet-Draft

  Adds requested_actor and actor_token so an agent is its own identity in the token.

  individual submission, not a WG document; version 02 (August 2025) at last check

• AI Agent Authentication and AuthorizationInternet-Draft

  Shows how existing standards (WIMSE, OAuth) can be combined for agents.

  individual submission with no IETF standing; version 03 at last check

Related: enterprise-managed authorization is an MCP extension that combines Token Exchange with the Identity Assertion JWT Authorization Grant.

Open problems

The OpenID Foundation's whitepaper Identity Management for Agentic AI is a good overview of the wider questions.

• Delegation and audit trail. When a user asks an agent, and the agent calls another agent, who did what? Token Exchange and the drafts above record the chain, but there is no single agreed pattern yet.
• Consent for long-running tasks. A person approves once, but an agent may keep working for hours. CIBA and step-up requests let a service ask again at the right moment, but this is still being worked out.
• Least-privilege scopes. Coarse scopes such as "read all files" give an agent more than it needs. Rich Authorization Requests and incremental scope requests aim to narrow this.
• Prompt injection. An agent may read text that tells it to misuse the access it already has. OAuth cannot stop this, because the token is valid. Narrow, short-lived tokens limit the damage.

What to watch

• Whether OAuth 2.1 is published as an RFC.
• Whether Transaction Tokens and Identity Chaining become RFCs, since agent designs lean on them.
• Client ID Metadata Documents replacing Dynamic Client Registration in MCP.
• Which of the agent-specific drafts the OAuth working group adopts.

Follow the OAuth working group documents for the current status of every draft above.