authorization requirements

7 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Auth applies to HTTP transports, not STDIO

MCP provides an Authorization framework for use with HTTP. Implementations using an HTTP-based transport SHOULD conform to that specification, whereas implementations using STDIO transport SHOULD NOT follow it and should instead retrieve credentials from the environment. Clients and servers MAY additionally negotiate their own custom authentication and authorization strategies.

iss parameter validation in authorization responses

Authorization servers SHOULD include the `iss` parameter in authorization responses per RFC 9207, and MCP clients MUST validate a present `iss` against the recorded issuer before redeeming the authorization code (SEP-2468).

application_type required in Dynamic Client Registration

MCP clients are required to specify an appropriate `application_type` during Dynamic Client Registration to avoid OpenID Connect redirect URI conflicts (SEP-837).

Client credentials bound to issuing authorization server

Client credentials are bound to the authorization server that issued them: clients MUST key persisted credentials by the issuer identifier, MUST NOT reuse them with a different authorization server, and MUST re-register when the authorization server changes (SEP-2352).

OAuth Dynamic Client Registration deprecated in favor of Client ID Metadata Documents

The OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591) is deprecated as a client registration mechanism in favor of Client ID Metadata Documents (PR #2858). DCR remains available for backwards compatibility with authorization servers that do not support Client ID Metadata Documents.

Dynamic Client Registration deprecated in 2026-07-28

OAuth Dynamic Client Registration (basic/authorization/client-registration#dynamic-client-registration) was deprecated in revision 2026-07-28 via PR #2858. Migration path: use Client ID Metadata Documents. Earliest removal: the first revision released on or after 2027-07-28.

cacheScope public vs private MUST NOT share caches

`cacheScope` is analogous to HTTP `Cache-Control: public` vs `private`. "public" means the response contains no user-specific data, so any client or intermediary (shared gateway, caching proxy) MAY cache it and serve it across authorization contexts. "private" means the response MAY be cached and reused only within the same authorization context; caches MUST NOT be shared across authorization contexts (e.g., a different access token requires a different cache).

Give your agent this brain