MCP Authentication — References

This capability is unusually well served by published standards: almost everything below is an IETF specification that the protocol's authorisation design builds on directly.

The protocol's own authorisation story

• Model Context Protocol — the specification and documentation, including how authorisation is layered onto the HTTP-based transport. Linked at the root: the authorisation section has been revised substantially between releases and deep links go stale.

Core authorisation framework

• RFC 6749: The OAuth 2.0 Authorization Framework — grant types, client types, and the role separation between client, resource server, and authorisation server that the rest of this list assumes.
• RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage — presenting a token and, more usefully here, the WWW-Authenticate challenge a resource returns when one is missing or insufficient.
• RFC 7636: Proof Key for Code Exchange by OAuth Public Clients — the interception defence that any client which cannot keep a secret must implement.
• RFC 8252: OAuth 2.0 for Native Apps — redirect handling for applications running on a user's own machine, which covers most hosts that connect to local servers.
• OAuth 2.0 Security Best Current Practice — the IETF OAuth working group's consolidated guidance superseding the original threat model, including the current position on implicit flow, redirect validation, and token replay. Cited by name without a number, which this document is not confident of.
• RFC 6819: OAuth 2.0 Threat Model and Security Considerations — the original systematic enumeration of attacks against these flows.

Binding a credential to its target

• RFC 8707: Resource Indicators for OAuth 2.0 — requesting a credential for a specific resource, the mechanism behind audience binding.
• RFC 9068: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens — the claim set a resource server validates, audience included.
• RFC 7519: JSON Web Token (JWT) — the token format itself and its validation rules.
• RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) — binding a token to a key so that theft alone does not permit use.
• RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens — the certificate-based equivalent for service-to-service connections.
• RFC 8693: OAuth 2.0 Token Exchange — exchanging one credential for another scoped to a downstream, and the delegation versus impersonation distinction.

Discovery and client onboarding

• RFC 9728: OAuth 2.0 Protected Resource Metadata — how a resource publishes which authorisation servers it accepts, so a client can follow a challenge instead of being configured.
• RFC 8414: OAuth 2.0 Authorization Server Metadata — the corresponding publication on the authorisation server side.
• RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol — registering a client without an administrator, and the software-statement mechanism for constraining who may.
• RFC 8615: Well-Known Uniform Resource Identifiers — the path convention all of the above metadata documents are published under.

Non-user identity

• SPIFFE — workload identity and attestation for connections where the caller is a service rather than a person.

No verified reference is recorded for authenticating a server spawned as a local child process. There is no protocol answer to that case; the available controls are package provenance and operating-system confinement, covered in the sandbox capability.