MCP OAuth is the authorization part of the Model Context Protocol specification. It makes the MCP server an OAuth 2.1 resource server: the server publishes a metadata document saying which authorization server guards it, and an AI client that has never seen your software before reads that document and runs a standard browser sign-in on the user's behalf. The result is a short-lived access token bound to that one server, carrying the user's own identity and permissions. The user pastes a URL and signs in. They never handle a credential.

Is MCP OAuth the same as normal OAuth?

It is standard OAuth 2.1 with one problem added that ordinary OAuth never has to solve. In a normal integration the client's developer already knows the service, has read its documentation and has registered the application in advance. An MCP client has none of that: it starts with a URL a user pasted. So the specification adds discovery, which is Protected Resource Metadata (RFC 9728), and audience binding, which is Resource Indicators (RFC 8707), so a token issued for one MCP server cannot be replayed against another.

What Is MCP OAuth? The Authorization Flow Explained

MCP OAuth is the authorization flow defined by the Model Context Protocol specification. It makes your MCP server an OAuth 2.1 resource server, so an AI client like Claude or ChatGPT can discover where to authenticate and run the sign-in itself, without the user ever handling an API key.

What it replaces

Before it, connecting an AI assistant to a business system meant an API key. Someone with admin access created one, sent it to the user, and the user pasted it into a JSON configuration file.

That has five problems, and they are all familiar: a person has to issue it, it has to travel over some channel, it usually carries the issuer's permissions rather than the user's, it does not expire, and the user has to store it somewhere. The last one is the one that caps adoption, because it means the feature only ever reaches people who will edit a config file.

The problem the spec had to solve

Ordinary OAuth assumes the client already knows the service. A developer read the docs, registered an application, and holds a client ID.

An MCP client knows nothing. Claude does not ship with an integration for your ERP. It has one string: the URL a user pasted into a settings dialog.

So MCP OAuth answers a question normal OAuth never asks: given only a resource URL, how does a client find out where to authenticate?

How the flow works

Five steps, of which the user sees two.

The client calls your MCP endpoint with no token. You answer 401 with a WWW-Authenticate header carrying a resource_metadata parameter.
The client fetches that document at /.well-known/oauth-protected-resource. It names your canonical resource URI and, in authorization_servers, at least one authorization server.
The client fetches the authorization server metadata, at /.well-known/oauth-authorization-server or via OpenID Connect Discovery, learning your authorize, token and registration endpoints.
The client obtains a client ID, now normally by publishing a Client ID Metadata Document at a URL it controls.
The user signs in and approves a consent screen. Standard authorization code flow with PKCE, carrying a resource parameter naming your server. The code is exchanged for a short-lived access token whose audience is your server.

Every request after that carries Authorization: Bearer <token>.

What you get that an API key does not give you

The token carries the user's own identity, not a shared secret's. It expires on its own. It can be revoked centrally. And when your authorize endpoint reuses your application's existing session, the user's AI access is by construction their normal access, which means your existing offboarding already covers it.

What it does not give you is authorization. The token says who is calling. It says nothing about what they may do, so every tool still has to be scoped to the caller's real permissions on the server side.

Which spec version

The 2025-06-18 revision is the one that matters: it reclassified MCP servers as OAuth resource servers and made RFC 9728 discovery mandatory. The current revision, 2026-07-28, makes Client ID Metadata Documents the recommended registration path and deprecates Dynamic Client Registration.

This is the short answer. The long one, with the handshake in full, what it costs to implement on an existing application, and the five things that break it silently, is in the auth change that moved MCP setup off the user.

If you are weighing whether your own platform should expose an MCP server, that is what we build.