# MCP OAuth: authorization, scopes and token exchange (2026)

> How MCP OAuth works in the 2026-07-28 spec: Protected Resource Metadata, resource indicators, per-tool scopes, Okta and Entra token exchange, and what Tyk Gateway enforces.

MCP OAuth uses OAuth 2.1 to authorize access to protected HTTP-based MCP servers; the [current published MCP version](https://modelcontextprotocol.io/docs/2026-07-28/learn/versioning) on 30 October 2026 is 2026-07-28. The authorization framework requires [Protected Resource Metadata, RFC 9728](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/authorization-server-discovery), [resource indicators, RFC 8707](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations), and [tokens issued for the intended MCP resource, with no token passthrough to distinct downstream APIs](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations). [Tyk Gateway 5.14](https://tyk.io/docs/ai-management/mcp-gateway/oauth-2-1) provides OAuth proxying, Protected Resource Metadata mirroring and scope enforcement for tools, resources and prompts.

*Disclosure: this guide is published by Tyk, so Tyk is described in more detail than other gateways. Checked against the MCP specification and Tyk documentation on 30 October 2026.*

## Which MCP authorization requirements changed by spec version?

MCP authorization is optional at the protocol level. The requirements below apply to the HTTP authorization framework; local stdio implementations use a different credential model. MUST, SHOULD and MAY retain their meanings from the [MCP authorization specification](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization).

| MCP specification | Protected Resource Metadata | Resource indicators | Client registration | Token passthrough |
| --- | --- | --- | --- | --- |
| [2025-03-26](https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization) | PRM not specified; authorization-server metadata and fallback endpoints described. | RFC 8707 resource parameter not specified. | DCR SHOULD be supported; CIMD not specified. | No explicit ban in this chapter; third-party flow described separate MCP tokens. |
| [2025-06-18](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization) | PRM MUST be implemented; 401 responses advertise metadata. | Required in authorization and token requests. | DCR SHOULD be supported; CIMD not specified. | Explicitly prohibited; separate upstream tokens required. |
| [2025-11-25](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization) | PRM required; challenge or well-known discovery supported. | Required in both request types. | CIMD SHOULD be supported; DCR MAY be supported. | Prohibition retained. |
| [2026-07-28, current](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) | PRM and discovery requirements retained. | Required in both request types. | CIMD SHOULD be supported; DCR deprecated, still MAY for compatibility. | Prohibition retained; issuer protections strengthened. |

Client ID Metadata Documents (CIMD) and Dynamic Client Registration (DCR) identify OAuth clients. DCR has not been removed. OAuth 2.1 itself remains an [IETF Internet-Draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/); MCP specifies the framework and additional interoperability requirements.

## How does MCP OAuth work, step by step?

An MCP OAuth authorization-code flow involves the MCP client, the protected MCP server, an authorization server and the user granting access. The authorization server issues tokens; the MCP resource server evaluates incoming requests. These are [distinct OAuth roles](https://www.rfc-editor.org/rfc/rfc6749.html), even when components share an operator.

1. The MCP client requests a protected endpoint. Without a usable credential, the server returns a 401 response. The client discovers resource metadata through a challenge header or a well-known location, following [MCP discovery rules](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/authorization-server-discovery).
2. The client reads PRM to identify the resource and authorization servers. The client then retrieves [authorization-server metadata](https://www.rfc-editor.org/rfc/rfc8414.html) containing endpoints and capabilities. Resource metadata and issuer metadata describe different entities.
3. The client obtains a client ID. For clients supporting every method, the [recommended registration priority](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration) is existing preregistration, supported CIMD, then supported DCR, with manual registration as a fallback.
4. The client starts authorization with requested scopes and the MCP server's canonical URI in resource. The authorization server authenticates the user and applies consent policy. For the authorization-code flow, the client uses [PKCE, using S256 when technically capable, and verifies advertised PKCE support](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations).
5. The client validates the authorization response and redeems the code. MCP requires resource in [both the authorization request and token request](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization). An omitted resource parameter can break audience binding.
6. The client sends the access token using the [Authorization: Bearer header](https://www.rfc-editor.org/rfc/rfc6750.html). The resource server validates the token and applies the requested operation's authorization policy before execution.
7. If the operation calls another protected API, the MCP server obtains an appropriate downstream token. [RFC 8693 token exchange](https://www.rfc-editor.org/rfc/rfc8693.html) is one possible mechanism, not a mandatory step for every MCP request.

Authorization-response issuer checking matters too. Following [RFC 9207](https://www.rfc-editor.org/rfc/rfc9207.html), compare a returned iss value with the expected issuer before redeeming the code. Reject a missing iss when the authorization server advertised support for that parameter.

The following PRM document is illustrative, with placeholder hostnames and an application-defined scope. [RFC 9728](https://www.rfc-editor.org/rfc/rfc9728.html) defines these fields. The example describes discovery metadata, not a complete server configuration or an executed test.

```
{
  "resource": "https://mcp.example.com/mcp",
  "authorization_servers": ["https://login.example.com"],
  "scopes_supported": ["orders:read"],
  "bearer_methods_supported": ["header"]
}
```

MCP 2026-07-28 removed the initialize handshake. An OAuth walkthrough should therefore begin with a protected request, not assume every client first creates an MCP session. The [official release announcement](https://blog.modelcontextprotocol.io/posts/2026-07-28/) explains the stateless request model.

## How do MCP authentication and authorization differ?

MCP server authentication establishes whether a presented credential is valid for the caller and resource. Authorization determines whether that caller can perform the requested action. [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html) adds user authentication to OAuth; an ID token describes a login and is not a substitute for the access token intended for an MCP server.

A signed token can still be unsuitable: the issuer may be untrusted, the audience may identify another API, or the granted permissions may be insufficient. [MCP requires audience validation](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations). Under [Bearer-token error handling](https://www.rfc-editor.org/rfc/rfc6750.html), invalid tokens normally produce 401, while insufficient scope produces 403.

Consider an order-support assistant. A successful employee login does not imply permission to cancel orders. Design the authorization policy around permitted actions and business records, then use the token as evidence for that decision.

## How should per-tool OAuth scopes work?

Per-tool MCP authorization maps application permissions to concrete operations. OAuth leaves scope meanings to the authorization server and resource service; [RFC 6749](https://www.rfc-editor.org/rfc/rfc6749.html) defines the scope mechanism, not a universal MCP tool vocabulary. In an illustrative order service, orders:read permits read-order, while orders:cancel permits cancel-order.

Keep the resource audience and scope separate: [resource identifies the target service](https://www.rfc-editor.org/rfc/rfc8707.html); scope describes requested access. A token for a reporting API does not become valid at an orders MCP server merely because both systems recognize orders:read.

[MCP scope challenges](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) describe the attempted operation and can differ from PRM's advertised scopes. Step-up authorization combines previously requested scopes with newly required scopes and limits retries, so clients do not repeatedly submit an insufficient token.

Design the order-service policy so a read-only assistant cannot cancel an order by naming cancel-order directly. Discovery filtering helps clients find permitted capabilities, but a hidden name remains guessable. Test direct invocation separately from tools/list, and apply record ownership or tenant rules within the application.

For this example, the acceptance checks are: read succeeds with the correct audience and orders:read; cancellation fails with that same token; a wrong-audience token fails even with orders:cancel; and cancellation succeeds only with the required scope and record permission. These are proposed checks, not reported test results. The [MCP server access-control guide](https://tyk.io/learning-center/mcp-server-access-control-guide/) develops the operation-level model.

## How do Okta, Microsoft Entra and token exchange fit together?

Enterprise MCP authorization has two separate credential decisions: the token the client presents to the MCP resource, and any token the MCP service needs for a downstream API. [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693.html) lets a service exchange an incoming subject token for another token with the target audience and permissions approved by the authorization server.

[Microsoft Entra's MCP configuration](https://learn.microsoft.com/en-us/entra/agent-id/secure-mcp-server-with-entra-id) requires the app registration to accept v2 access tokens, using requestedAccessTokenVersion: 2, and aligns the Application ID URI with the canonical MCP resource URL. Token format version and MCP protocol version are separate settings.

[Okta documents token exchange](https://developer.okta.com/docs/guides/set-up-token-exchange/main/) using the token-exchange grant and subject\_token to retain user context for downstream access. [Microsoft Entra On-Behalf-Of (OBO)](https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-on-behalf-of-flow) uses the jwt-bearer grant, assertion and requested\_token\_use=on\_behalf\_of. Entra OBO operates with delegated user scopes, not app-only principals. The protocols require different request configuration.

Check the IdP's accepted grant, client authentication, consent and audience mapping before configuring the gateway. A generic claim of OAuth support does not establish interoperability with every registration or exchange mechanism.

[Enterprise-Managed Authorization](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization) is a separate MCP extension: an enterprise IdP supplies an Identity Assertion JWT Authorization Grant, which the client exchanges at the MCP server's authorization server. Ordinary corporate login does not establish extension support. MCP [authorization extensions require explicit implementation support](https://modelcontextprotocol.io/extensions/auth/overview).

## What can Tyk Gateway enforce for MCP authorization?

[Remote MCP proxies are available from Tyk Gateway 5.13 across Gateway licences, including open source](https://tyk.io/docs/ai-management/mcp-gateway/overview). That proxy availability does not establish the licence tier of every OAuth feature. For deployment context, see [MCP gateway architecture and use cases](https://tyk.io/learning-center/mcp-gateway-explained-architecture-use-cases/).

- Available in Tyk Gateway 5.14: OAuth proxying and [automatic PRM mirroring for remote MCP upstreams](https://tyk.io/docs/api-management/authentication/oauth2-authentication), plus [scope enforcement per tool, resource and prompt](https://tyk.io/docs/ai-management/mcp-gateway/mcp-middleware).
- Tyk Gateway 5.14 adds filtering of tools/list, resources/list and prompts/list through OAS-level allow/block rules, according to the [release notes](https://tyk.io/docs/developer-support/release-notes/gateway). Scope enforcement and discovery filtering are separate controls.
- [RFC 8693 token exchange is Enterprise-only from 5.14.0](https://tyk.io/docs/api-management/authentication/token-exchange). Tyk replaces the inbound credential with an upstream-scoped token; provider and per-primitive settings control the exchange.
- Tyk Gateway 5.16, [released 27 October 2026](https://tyk.io/docs/developer-support/release-notes/gateway), supports [MCP 2026-07-28 alongside 2025-11-25 and adds Origin-header validation](https://tyk.io/docs/ai-management/mcp-gateway/protocol-versions).

For Tyk 5.14.0, configure JWT authentication alongside the oauth2 scheme: [the OAuth scheme reads claims but does not validate JWT signatures itself](https://tyk.io/docs/ai-management/mcp-gateway/oauth-2-1). Tyk also documents OAuth scope enforcement and key-based primitive access policies as alternative authorization models for the same primitive. Choose the model deliberately.

The following illustrative fragment belongs inside x-tyk-api-gateway in an existing MCP OAS definition. Declare idpAuth as an OAuth2 scheme, enable JWT validation, and configure the scheme's scope checker. Use [scopeSource: operation](https://tyk.io/docs/api-management/authentication/oauth2-authentication) for this example so broader root alternatives do not satisfy a tool-specific scope requirement. The [primitive fields](https://tyk.io/docs/ai-management/mcp-gateway/mcp-middleware) follow Tyk documentation; the fragment has not been deployment-tested.

```
{
  "middleware": {
    "mcpTools": {
      "read-order": {
        "security": [{ "idpAuth": ["orders:read"] }],
        "scopeCheck": { "enabled": true }
      },
      "cancel-order": {
        "security": [{ "idpAuth": ["orders:cancel"] }],
        "scopeCheck": { "enabled": true }
      }
    }
  }
}
```

[Tyk policies](https://tyk.io/docs/ai-management/mcp-gateway/policies) also govern JSON-RPC methods and named primitives, with rate limits at four levels: policy, MCP proxy, JSON-RPC method and primitive. Rate limits constrain usage; the order-service acceptance checks above still need to establish authorization behavior.

## When is Tyk not the right choice?

Tyk MCP Gateway is not a direct fit for a stdio-only integration or legacy HTTP+SSE endpoint: [Tyk supports Streamable HTTP only](https://tyk.io/docs/ai-management/mcp-gateway/core-concepts). Streamable HTTP may carry SSE responses; that does not mean support for the separate legacy transport.

An open-source-only requirement also excludes [Tyk's Enterprise token exchange](https://tyk.io/docs/api-management/authentication/token-exchange) and [REST-to-MCP generation, which requires Enterprise 5.15 or later and a Tyk OAS source API](https://tyk.io/docs/ai-management/mcps/api-to-mcp). Check the Gateway release notes for the edition that includes each OAuth feature.

[Tyk documents strict issuer-checking failures in PRM mirror mode](https://tyk.io/docs/ai-management/mcp-gateway/oauth-2-1), so validate discovery with the intended client. Tyk's [air-gapped installation guide](https://tyk.io/docs/api-management/air-gapped-deployment) covers offline deployment assets. An isolated architecture still needs reachable identity, metadata and token services; installing a gateway does not remove a cloud IdP's network dependency.

## Which mistakes break MCP OAuth integrations?

- Protecting discovery behind the token being discovered. [PRM retrieval](https://www.rfc-editor.org/rfc/rfc9728.html) must work before the client obtains the resource's access token.
- Treating a valid signature as permission for every API. [MCP security guidance](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices) forbids accepting tokens issued for another resource and passing those tokens downstream.
- Trusting issuer names without checking metadata. [MCP discovery](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/authorization-server-discovery) requires matching issuer metadata and separate client state for different authorization servers.
- Assuming discovery filtering proves invocation protection. Attempt the hidden tool directly, and confirm the operation cannot change stored data without authorization.
- Logging bearer credentials while debugging. [Bearer tokens require protection from disclosure](https://www.rfc-editor.org/rfc/rfc6750.html); record outcomes and request identifiers without recording reusable credentials.

Review these failures alongside the broader [enterprise MCP server security guide](https://tyk.io/learning-center/mcp-server-security-ai-enterprise-guide/). Separate token validation, operation permission and downstream credential handling in the review.

## What are the common MCP server authentication questions?

### What is MCP server authentication?

MCP server authentication checks a caller's credential before protected operations run. OAuth access tokens carry access grants; OpenID Connect ID tokens describe user authentication and should not replace an MCP resource's access token. See [OpenID Connect Core](https://openid.net/specs/openid-connect-core-1_0.html).

### Does every MCP server need OAuth?

No. MCP authorization is optional. The HTTP authorization specification defines OAuth-based access when authorization is supported; stdio implementations should obtain credentials from the environment instead. See the [MCP authorization specification](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization).

### Is DCR required for MCP OAuth?

No. MCP 2026-07-28 recommends CIMD support and deprecates DCR while retaining DCR for compatibility. Existing preregistration remains supported. CIMD uses an HTTPS client metadata URL as the client identifier. See [MCP client registration](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration).

### What do MCP OAuth resource indicators do?

Resource indicators identify the service for which a client requests an access token. The resource server must still validate the issued token's audience; sending a resource parameter alone does not establish valid access. See [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html).

### Can an MCP server pass a client token to another API?

MCP prohibits token passthrough across distinct protected resources. The MCP server validates its incoming token and obtains an appropriate separate credential for downstream API access. A reverse proxy still needs correct resource identity and token validation. See [MCP security guidance](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices).

### Can MCP authorization use Microsoft Entra or Okta?

Yes, with the corresponding resource, client and authorization-server configuration. Microsoft documents Entra-secured MCP servers; [Okta documents MCP integration](https://developer.okta.com/docs/api/secures-ai/mcp-servers) and delegated token exchange. [Entra OBO](https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-on-behalf-of-flow) and RFC 8693 exchange require different request formats. See [Microsoft's MCP setup](https://learn.microsoft.com/en-us/entra/agent-id/secure-mcp-server-with-entra-id) and [Okta's exchange guide](https://developer.okta.com/docs/guides/set-up-token-exchange/main/).

### What is enterprise-managed MCP authorization?

Enterprise-Managed Authorization is an optional MCP extension that lets an enterprise identity provider govern MCP access through an ID-JAG exchange. Corporate SSO alone does not establish extension support. See the [Enterprise-Managed Authorization extension](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization).