MCP server OAuth and authorization

The MCP server is an OAuth resource server. The MCP client is an OAuth client acting for a person. The authorization server signs that person in and issues tokens, and it can be part of the MCP server or a separate system such as your existing identity provider.

The client starts by sending an MCP request with no token. The server answers 401, and its WWW-Authenticate header can point to the Protected Resource Metadata document and name the scopes to request.

That document lists one or more authorization servers. The client then reads the chosen server’s metadata, through OAuth Authorization Server Metadata or OpenID Connect Discovery, to learn its endpoints.

A client needs a client ID, and most MCP clients and servers have never met. The specification lists these options in priority order for a client that supports them all: pre-registered details, Client ID Metadata Documents, then Dynamic Client Registration.

With a metadata document, the client ID is an HTTPS URL pointing to a JSON file that names the client and its redirect URIs. Dynamic Client Registration is deprecated as of this revision and remains available for authorization servers that have not moved.

The client opens the browser with a PKCE challenge and a resource parameter, the person approves access, and the client redeems the code for tokens. These are the requirements that catch implementers most often:

A token can be valid and still lack the permission for one tool. The server should then answer 403 with error="insufficient_scope" and the scopes it needs. A client acting for a person should run the authorization flow again for the larger set and retry a limited number of times.

This is what lets a server start with narrow scopes. The first sign-in stays short, and the person sees a request for more access at the moment a tool needs it.

The server validates each access token and confirms it was issued for this server, using the audience claim or an equivalent check. A missing or invalid token gets 401 and a token with too little scope gets 403. Authorization goes on every HTTP request, including requests that belong to one logical workflow.

The hosted server publishes Protected Resource Metadata and answers an unauthenticated request with a 401 challenge that points to the authorization server.

With your own authorization server, Octri checks each token first through your JWKS or introspection endpoint, covering signature, issuer, expiry and audience.

With Octri signing people in to your OAuth, the person approves access on a consent page, the upstream token is kept encrypted, and refresh tokens rotate on every use.

Sign-in tokens are bound to the address they were issued on, so a token from your custom domain is refused on the default address.

Everyone who signed in is listed with their client and last call, and you can end any grant from that list.