Zuplo

Authorization and tokens

What a server checks on the token it receives, and what it must refuse to do with it.

OPTIONAL authorization

The MCP specification states that authorization is OPTIONAL for implementations, and that HTTP-based implementations SHOULD — not MUST — conform to its OAuth profile when they do support it. #

The MCP specification states that authorization is OPTIONAL for implementations, and that HTTP-based implementations SHOULD — not MUST — conform to its OAuth profile when they do support it. stdio implementations should not follow the profile at all, and should take credentials from the environment instead.

Where you meet it

So an MCP server behind an API key or a custom header is outside the specification's OAuth profile, not in violation of it. That distinction matters because most working servers are configured that way, and the tradeoff is real rather than moral: only the OAuth profile gets a server into a connector directory, because that is the only credential a client you do not control knows how to obtain.

Also written: authorization is optional · MCP API key auth · custom header auth MCP · is API key authentication allowed in MCP · out of scope

Source: MCP 2026-07-28: Protocol Requirements
On this site: API key authentication for MCP servers MCP authentication methods
Read next: WWW-Authenticate stdio Token passthrough

Resource indicators

RFC 8707 defines a resource request parameter that names the target service a token is being requested for, so the authorization server can audience-restrict the token it issues. #

RFC 8707 defines a resource request parameter that names the target service a token is being requested for, so the authorization server can audience-restrict the token it issues. MCP clients must send it on both the authorization request and the token request, must set it to the MCP server they intend to call, and must send it whether or not the authorization server supports it.

Where you meet it

The value is the MCP server's canonical URI: an absolute URI with no fragment, such as https://mcp.example.com/mcp. Several identity providers ignore resource and expect the audience some other way, which is where audience mismatches begin. An authorization server that rejects the value returns invalid_target.

Also written: resource indicators · RFC 8707 · resource parameter · resource indicator missing or unknown · canonical server URI

Source: RFC 8707, Section 2 MCP 2026-07-28: Resource Parameter Implementation
On this site: Resource indicator missing or unknown
Read next: Audience PRM Token passthrough

Audience

The party a token is intended for. #

The party a token is intended for. In a JWT this is the aud claim, which RFC 7519 defines as identifying the recipients that the JWT is intended for; where the claim is present, a recipient that does not identify itself in it must reject the token. MCP servers must validate that an access token was issued specifically for them as the intended audience.

Where you meet it

Audience binding is what stops a token minted for one MCP server from working on another. It is the check that fails when an identity provider ignored the resource parameter and issued a token audienced at itself, or at your API rather than your MCP server.

Also written: audience · aud claim · aud · token audience · audience validation failed

Source: RFC 7519, Section 4.1.3 MCP 2026-07-28: Token Handling
On this site: Token audience validation failed
Read next: Resource indicators Token passthrough Token exchange

Issuer identification

Changed in 2026-07-28 RFC 9207 adds an iss parameter to the OAuth authorization response so a client can tell which authorization server issued the code it just received, and an authorization_response_iss_parameter_supported metadata flag to advertise it. #

RFC 9207 adds an iss parameter to the OAuth authorization response so a client can tell which authorization server issued the code it just received, and an authorization_response_iss_parameter_supported metadata flag to advertise it. MCP authorization servers should include iss, and clients must validate a present iss against the issuer they recorded from validated metadata before sending the code to any token endpoint.

This revision made client-side validation of a present iss a MUST (SEP-2468), and says a future revision is expected to upgrade server inclusion from SHOULD to MUST.

Where you meet it

It defends against mix-up attacks, where a client that talks to more than one authorization server is tricked into sending a code or token to the wrong one. A client that uses only one authorization server is not vulnerable. The validation applies to error responses too: on a mismatch the client must not act on or display error or error_description.

Also written: iss · iss parameter · RFC 9207 · authorization_response_iss_parameter_supported · mix-up attack

Source: RFC 9207, Section 2 MCP 2026-07-28: Authorization Response Validation
On this site: OAuth 2.1 authentication for MCP servers
Read next: ASM PKCE

Scope

The OAuth mechanism for expressing what an access token is allowed to do. #

The OAuth mechanism for expressing what an access token is allowed to do. When a token is valid but lacks the permission a request needs, the server should return 403 Forbidden with a WWW-Authenticate challenge carrying error="insufficient_scope" and a scope parameter naming the scopes the operation requires.

Where you meet it

The client then runs a step-up authorization flow, requesting the union of the scopes it already asked for and the ones in the challenge, so previously granted permissions are not lost. A server should put every scope the operation needs into one challenge — challenging for one scope at a time forces a round trip per scope.

Also written: scope · scopes_supported · insufficient_scope · 403 insufficient scope · step-up authorization

Source: RFC 6750, Section 3.1 MCP 2026-07-28: Scope Challenge Handling
On this site: 401 without a WWW-Authenticate header
Read next: WWW-Authenticate Audience

Token passthrough

The anti-pattern in which an MCP server accepts a token from a client without validating that it was issued to the MCP server, then passes it through to a downstream API. #

The anti-pattern in which an MCP server accepts a token from a client without validating that it was issued to the MCP server, then passes it through to a downstream API. The specification forbids both halves: MCP servers must only accept tokens that are valid for use with their own resources and must not accept or transit any other tokens, and a server calling an upstream API must not pass through the token it received from the client.

Where you meet it

It is the shortcut that makes a demo work and an audit fail, because it destroys the audience binding every other control depends on and can turn the server into a confused deputy — the downstream API trusts the token as if the MCP server had issued or validated it. To reach a downstream API with a different audience, exchange the token rather than forwarding it.

Also written: token passthrough · token pass-through · forwarding access tokens · confused deputy

Source: MCP 2026-07-28: Token Handling MCP 2026-07-28: Security Best Practices, Token Passthrough
On this site: Token audience validation failed
Read next: Audience Token exchange Resource indicators

Token exchange

An OAuth grant, defined by RFC 8693, in which a client presents one token and receives a different one with a different audience, subject, or scope. #

An OAuth grant, defined by RFC 8693, in which a client presents one token and receives a different one with a different audience, subject, or scope. The grant_type is urn:ietf:params:oauth:grant-type:token-exchange, the incoming token goes in subject_token, and an optional actor_token names the party acting on the subject's behalf.

Where you meet it

It is the correct answer to "my MCP server needs to call a downstream API as the user" — the alternative, forwarding the incoming token, is forbidden. RFC 8693 distinguishes delegation, where the acting party keeps its own identity, from impersonation, where it takes on the subject's.

Also written: token exchange · RFC 8693 · urn:ietf:params:oauth:grant-type:token-exchange · subject_token · delegation · impersonation

Source: RFC 8693, Section 2.1 RFC 8693, Section 1.1 (delegation versus impersonation)
On this site: Machine-to-machine MCP authentication
Read next: Token passthrough Audience ID-JAG