# MCP Authorization Source: https://startwithidentity.com/standards/mcp-authorization/ Last updated: 2026-11-05 License: content by Start with Identity. Cite the source URL. --- ## What it is MCP authorization is the part of the [Model Context Protocol](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) that says how an AI client (an agent, IDE or chat app) gets permission to call a remote MCP server on a user's behalf. The answer is plain OAuth, profiled tightly: the **MCP server** is an OAuth 2.1 resource server, the **MCP client** is an OAuth 2.1 client, and a separate **authorization server** issues tokens. The specification picks "a selected subset" of existing standards rather than inventing new ones. That choice matters for practitioners. Securing MCP is mostly about running OAuth correctly, and the [MCP authorization glossary entry](https://startwithidentity.com/glossary/mcp-authorization/) gives the one-paragraph version. This page covers what the current revision requires and what it leaves to you. ## Status (November 2026) The current MCP protocol version is **2026-07-28**, per the [MCP versioning page](https://modelcontextprotocol.io/specification/versioning) read on 5 November 2026. Earlier revisions are 2025-11-25, 2025-06-18, 2025-03-26 and 2024-11-05. MCP is hosted by the Linux Foundation's Agentic AI Foundation, to which Anthropic [donated it](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation) in December 2025. "Stable" here means a released protocol revision, not an IETF or OpenID standard. The revision depends on two moving IETF drafts. It cites **OAuth 2.1 draft-13**, while the draft has reached [-17](https://startwithidentity.com/standards/oauth-2-1/) (31 October 2026). It makes **Client ID Metadata Documents** the preferred registration method and cites revision -00, while the [OAuth working-group draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/) is at -03 (2 November 2026, WG Document). Everything else it relies on is a published RFC. Two authorization extensions are stable for 2026-07-28, in the [ext-auth repository](https://github.com/modelcontextprotocol/ext-auth): **OAuth Client Credentials** (agents acting as themselves) and **Enterprise-Managed Authorization** (ID-JAG). The DPoP profile, [SEP-1932](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1932), is open. ## How it works A concrete flow, a coding agent connecting to `https://mcp.example.com/mcp` for the first time: 1. **Challenge.** The client sends an MCP request without a token. The server answers `401` with `WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource", scope="files:read"`. 2. **Resource metadata ([RFC 9728](https://www.rfc-editor.org/rfc/rfc9728.html)).** The client fetches that document, which names one or more authorization servers. Servers must implement RFC 9728; if the header is missing, clients probe the well-known path for the MCP endpoint and then the root. 3. **Authorization server metadata.** The client tries RFC 8414 and OpenID Connect discovery URLs in a set order, and must reject a document whose `issuer` does not match the URL it constructed. 4. **Registration.** Clients use this priority: a pre-registered client ID if one exists; a **Client ID Metadata Document** if the server sets `client_id_metadata_document_supported: true`; Dynamic Client Registration ([RFC 7591](https://www.rfc-editor.org/rfc/rfc7591.html)) as a deprecated fallback; finally, asking the user. With CIMD, the `client_id` is an HTTPS URL with a path (for example `https://app.example.com/oauth/client-metadata.json`) and the server fetches it to check `client_name` and `redirect_uris`. 5. **Authorization request.** The client opens the browser with an authorization code request carrying a [PKCE](https://startwithidentity.com/glossary/pkce/) challenge, the scope from the challenge, and `resource=https://mcp.example.com/mcp`. [RFC 8707 resource indicators](https://startwithidentity.com/glossary/resource-indicators/) are mandatory in both the authorization and the token request, and the client must send them even if the server ignores them. 6. **Issuer check.** On the redirect, the client compares the `iss` parameter with the issuer it recorded ([RFC 9207](https://www.rfc-editor.org/rfc/rfc9207.html)) before sending the code anywhere, which blocks mix-up attacks. 7. **Token and calls.** The client redeems the code with the PKCE verifier and `resource`, then sends `Authorization: Bearer` on every HTTP request. 8. **Step-up.** If a later tool call needs more, the server returns `403` with `error="insufficient_scope"` and the full set of required scopes. The client re-authorizes with the union of old and new scopes. The server-side rules are short and strict: validate every token, accept only tokens issued for this server as audience, and **never pass a received token through** to an upstream API. If the MCP server calls another API, it is an OAuth client there and gets its own token. ## Enterprise-managed authorization The per-server consent flow above works for individuals and breaks down in companies, where an employee might connect an agent to dozens of MCP servers and each grant is invisible to IT. The [Enterprise-Managed Authorization extension](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/enterprise-managed-authorization/2026-07-28/enterprise-managed-authorization.mdx) replaces it with [ID-JAG](https://startwithidentity.com/standards/id-jag-cross-app-access/): the client signs the user in through the corporate IdP, exchanges the ID token at the IdP for an ID-JAG whose audience is the MCP server's authorization server, and redeems that for an access token. The IdP evaluates admin policy at the exchange, so the enterprise decides which clients may reach which MCP servers. ## What it solves for AI agents and SaaS For SaaS vendors exposing an MCP server, the profile gives a known shape for security review: an OAuth resource server with audience-bound tokens, discoverable metadata and per-operation scopes. For agent builders, it removes the worst early practices: API keys pasted into config files, tokens valid at any server, and proxies that forward a user's token upstream. SWI's [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/) scores token audience binding and client registration at 5 of 5, largely because MCP requires them. What it leaves open: tokens are bearer tokens held by a process that reads untrusted input, so a [prompt-injected](https://startwithidentity.com/techniques/agent-instruction-injection/) agent can be steered into misusing a valid token. Scopes are coarse, so per-call limits need a policy engine such as [AuthZEN](https://startwithidentity.com/standards/authzen/). Revocation mid-task needs short lifetimes and [Shared Signals](https://startwithidentity.com/standards/shared-signals-framework/). ## Adoption signals (verified) - **Official MCP TypeScript SDK.** The [client auth module](https://github.com/modelcontextprotocol/typescript-sdk/blob/main/packages/client/src/client/auth.ts) checks `client_id_metadata_document_supported`, and the [auth extensions module](https://github.com/modelcontextprotocol/typescript-sdk/blob/main/packages/client/src/client/authExtensions.ts) implements the ID-JAG exchange, checked 5 November 2026. - **Okta Agent SSO**, generally available since 24 August 2026, [describes](https://www.okta.com/newsroom/press-releases/okta-brings-first-class-identity-to-ai-agents-with-agent-sso/) connecting Cross App Access agents to enterprise applications "and MCP servers". ## How to implement or evaluate - **Building an MCP server:** publish RFC 9728 metadata, return precise `scope` in challenges, validate `aud` against your canonical URI, reject everything else, and keep `offline_access` out of your advertised scopes. - **Running the authorization server:** support CIMD with a domain trust policy, PKCE with S256, the `iss` response parameter, short access-token lifetimes, and refresh-token rotation for public clients. Consider [DPoP](https://startwithidentity.com/glossary/dpop/) where clients support it. - **Deploying in an enterprise:** prefer pre-registration or Enterprise-Managed Authorization over open registration, and inventory which agents hold refresh tokens for which servers. - **Reviewing a vendor:** ask which MCP revision they implement, whether they still rely on DCR, and whether their server forwards tokens upstream. ## Pitfalls - **Token passthrough.** Forbidden by the spec and still common in quick proxies. - **Trusting the `resource` parameter alone.** If the authorization server ignores RFC 8707, the token may lack a narrow audience. Servers must still check it. - **Localhost redirect URIs in CIMD.** The security considerations warn about localhost redirect risks; restrict which domains' metadata documents you accept. ## Related [ID-JAG and Cross App Access](https://startwithidentity.com/standards/id-jag-cross-app-access/), [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/), [OAuth Transaction Tokens](https://startwithidentity.com/standards/oauth-transaction-tokens/), [AuthZEN](https://startwithidentity.com/standards/authzen/), the [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/) guide and the [AI agent identity tools ranking](https://startwithidentity.com/rankings/best-ai-agent-identity-tools/). Glossary: [Client ID Metadata Document](https://startwithidentity.com/glossary/client-id-metadata-document/), [protected resource metadata](https://startwithidentity.com/glossary/protected-resource-metadata/), [dynamic client registration](https://startwithidentity.com/glossary/dynamic-client-registration/), [agent registry](https://startwithidentity.com/glossary/agent-registry/), [credential brokering](https://startwithidentity.com/glossary/credential-brokering/).