---
title: "Authorization and tokens — MCP glossary"
description: "What a server checks on the token it receives, and what it must refuse to do with it."
canonicalUrl: "https://zuplo.com/learn/mcp/glossary/authorization"
pageType: "mcp-glossary-group"
---

# Authorization and tokens

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

One group of the [MCP glossary](/learn/mcp/glossary), which indexes every term A to Z.

## 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. 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](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization#protocol-requirements)

**On this site:** [API key authentication for MCP servers](/learn/mcp/authentication/api-key) · [MCP authentication methods](/learn/mcp/authentication)

**Read next:** [WWW-Authenticate](/learn/mcp/glossary/discovery#www-authenticate) · [stdio](/learn/mcp/glossary/transport#stdio) · [Token passthrough](/learn/mcp/glossary/authorization#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. 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](https://datatracker.ietf.org/doc/html/rfc8707#section-2) · [MCP 2026-07-28: Resource Parameter Implementation](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization#resource-parameter-implementation)

**On this site:** [Resource indicator missing or unknown](/learn/mcp/errors/resource-indicator-missing-or-unknown)

**Read next:** [Audience](/learn/mcp/glossary/authorization#aud) · [PRM](/learn/mcp/glossary/discovery#protected-resource-metadata) · [Token passthrough](/learn/mcp/glossary/authorization#token-passthrough)

## Audience

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](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3) · [MCP 2026-07-28: Token Handling](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization#token-handling)

**On this site:** [Token audience validation failed](/learn/mcp/errors/token-audience-validation-failed)

**Read next:** [Resource indicators](/learn/mcp/glossary/authorization#resource) · [Token passthrough](/learn/mcp/glossary/authorization#token-passthrough) · [Token exchange](/learn/mcp/glossary/authorization#token-exchange)

## Issuer identification

_Changed in 2026-07-28._ 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.

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.

**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](https://datatracker.ietf.org/doc/html/rfc9207#section-2) · [MCP 2026-07-28: Authorization Response Validation](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization#authorization-response-validation)

**On this site:** [OAuth 2.1 authentication for MCP servers](/learn/mcp/authentication/oauth-2-1)

**Read next:** [ASM](/learn/mcp/glossary/discovery#authorization-server-metadata) · [PKCE](/learn/mcp/glossary/credentials#pkce)

## Scope

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](https://datatracker.ietf.org/doc/html/rfc6750#section-3.1) · [MCP 2026-07-28: Scope Challenge Handling](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization#scope-challenge-handling)

**On this site:** [401 without a WWW-Authenticate header](/learn/mcp/errors/401-without-www-authenticate)

**Read next:** [WWW-Authenticate](/learn/mcp/glossary/discovery#www-authenticate) · [Audience](/learn/mcp/glossary/authorization#aud)

## 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 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](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization#token-handling) · [MCP 2026-07-28: Security Best Practices, Token Passthrough](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices#token-passthrough)

**On this site:** [Token audience validation failed](/learn/mcp/errors/token-audience-validation-failed)

**Read next:** [Audience](/learn/mcp/glossary/authorization#aud) · [Token exchange](/learn/mcp/glossary/authorization#token-exchange) · [Resource indicators](/learn/mcp/glossary/authorization#resource)

## 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. 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](https://datatracker.ietf.org/doc/html/rfc8693#section-2.1) · [RFC 8693, Section 1.1 (delegation versus impersonation)](https://datatracker.ietf.org/doc/html/rfc8693#section-1.1)

**On this site:** [Machine-to-machine MCP authentication](/learn/mcp/authentication/client-credentials)

**Read next:** [Token passthrough](/learn/mcp/glossary/authorization#token-passthrough) · [Audience](/learn/mcp/glossary/authorization#aud) · [ID-JAG](/learn/mcp/glossary/credentials#id-jag)