Once an MCP server leaves your laptop and lives on the internet, "who is calling this?" stops being optional. The spec answers it with OAuth — and the 2026 revisions tightened the rules so MCP slots cleanly into the identity systems enterprises already run. If OAuth to you is a fog of redirects and acronyms, here's the shape of it, MCP-specific and jargon-decoded.
The two roles: resource server vs authorization server
The key idea is separation. A protected MCP server is a resource server — it holds the tools and data, and it accepts requests carrying an access token. It does not issue those tokens. That job belongs to a separate authorization server, typically your existing identity provider. The MCP client is the OAuth client asking for access on the user's behalf. Keeping these roles apart is what lets you front an MCP server with Okta, Entra or Auth0 instead of building auth from scratch.
PKCE and protected-resource metadata
Any internet-facing MCP server must implement OAuth 2.1 with PKCE (Proof Key for Code Exchange, S256 method) — the flow that stops an intercepted authorization code from being replayed. Discovery is standardised too: the server implements OAuth 2.0 Protected Resource Metadata (RFC 9728), so a client that hits a 401 gets a WWW-Authenticate header pointing at a resource_metadata URL, or finds the same data at a well-known URI. The client reads that, learns which authorization server to talk to, and starts the flow — no hard-coding.
Discovery: OAuth metadata or OIDC
On the authorization-server side, MCP requires at least one of two discovery mechanisms: OAuth 2.0 Authorization Server Metadata, or OpenID Connect Discovery 1.0. Clients must support both. In plain terms, an MCP client can walk up to almost any standards-compliant identity provider and figure out the endpoints on its own — which is exactly why the spec leans on OIDC deployments enterprises have already stood up.
Audience-bound tokens
The subtle rule that prevents a whole class of attacks: a token issued for your MCP server is bound to that server as its audience (via resource indicators, RFC 8707). Your server must reject a token minted for somewhere else, and must never forward a user's token onward to an upstream API. That "no passthrough" discipline is the difference between a scoped delegation and a confused-deputy hole — the full argument is in token passthrough prevention.
Going further
This connects to the wider 2026-07-28 spec changes, which aligned MCP auth more closely with OAuth and OIDC. For the day-to-day rules, read MCP security best practices and permission scoping patterns. Hosting your own? Start with private MCP server hosting.