MCP Authentication and OAuth 2.1, Explained Step by Step

MCP authentication uses OAuth 2.1, the same family of standards behind "Sign in with Google" buttons. When an AI app connects to a protected remote MCP server, the user signs in and approves access. The app then gets a short-lived access token that works only for that one server.

Authorization is optional in MCP. A public weather server may need none. But any server that touches business data should use it, and the MCP authorization specification (version 2026-07-28) spells out exactly how.

This guide walks through the flow step by step in plain English. It is written for business owners, product managers and IT leads who need to understand what their developers are building. All details were checked against the official spec on 28 October 2026.

The four players

Every MCP sign-in involves four parties. Knowing who is who makes the rest easy.

The spec says the authorization server "may be hosted with the resource server or a separate entity." Many companies point their MCP server at an identity provider they already use. For a refresher on hosts, clients and servers, see how MCP works.

Remote vs local: when OAuth applies

The spec splits the rules by transport, meaning how the app and server talk:

• HTTP-based (remote) servers "SHOULD conform" to the authorization spec. This is where OAuth lives.
• STDIO (local) servers "SHOULD NOT follow this specification, and instead retrieve credentials from the environment." In practice that means an API key or token stored on the machine.

So when a vendor says "our MCP server supports OAuth," they mean the remote version. A local version will usually ask you to paste a key.

The MCP sign-in flow, step by step

Here is what happens the first time an AI app connects to a protected MCP server. The steps follow the flow diagram in the spec.

Step 1: The app knocks and is told to sign in

The app sends a request without a token. The server replies with HTTP 401 Unauthorized. Its WWW-Authenticate header points to a small metadata file, and it "SHOULD" list the scopes needed.

Step 2: The app finds the authorization server

The metadata file follows a standard called Protected Resource Metadata (RFC 9728). The spec says MCP servers "MUST implement" it, and clients "MUST use" it. It tells the app which authorization server to use.

The app then fetches that authorization server's own metadata. The spec requires authorization servers to offer either OAuth 2.0 metadata (RFC 8414) or OpenID Connect Discovery, and requires clients to support both.

Step 3: The app identifies itself

Before asking you to sign in, the app needs a client ID. The client registration page lists three ways, in this priority order for clients that support all of them:

1. Pre-registration: the app already has a client ID for this server.
2. Client ID Metadata Document (CIMD): the app uses an HTTPS URL as its ID. That URL hosts a JSON file with its name and allowed redirect addresses.
3. Dynamic Client Registration (DCR): the app registers itself on the fly. The spec now marks this as "deprecated," kept for older servers.
4. If none of these work, the app asks the user to enter client details.

CIMD fits MCP well because most AI apps and servers have never met before. The spec calls this "the most common" scenario.

Step 4: The app prepares a secure request

The app now builds the sign-in link with three safeguards:

• PKCE (Proof Key for Code Exchange): a one-time secret pair that proves the app finishing sign-in is the app that started it. The authorization security considerations say clients "MUST implement PKCE" and use the S256 method when they can. If the server's metadata does not show PKCE support, the client "MUST refuse to proceed."
• Resource indicator (RFC 8707): the resource parameter names the exact MCP server the token is for, such as https://mcp.example.com. The spec says it "MUST" be included in both the sign-in and token requests.
• Scopes: the permissions requested, ideally only what the 401 response asked for.

Step 5: You sign in and approve

Your browser opens the authorization server's page. You sign in and approve the request. The server sends your browser back to the app with a one-time authorization code.

Before redirecting you, the app records which authorization server it expected. It then checks the iss (issuer) value in the response before using the code. This blocks "mix-up attacks," where a malicious server tries to grab a code meant for an honest one.

Step 6: The app swaps the code for a token

The app sends the code, its PKCE secret and the resource name to the token endpoint. It gets back an access token, and possibly a refresh token.

Step 7: Every request carries the token

From now on, the app sends Authorization: Bearer <token> on every request. The spec says tokens "MUST NOT be included in the URI query string," so they do not leak into logs and browser history.

What the MCP server must check

The server's side matters just as much. The spec says MCP servers:

• "MUST validate access tokens" before processing a request.
• "MUST validate that access tokens were issued specifically for them as the intended audience."
• "MUST only accept tokens that are valid for use with their own resources."
• "MUST NOT accept or transit any other tokens."

That last rule bans "token passthrough." If your MCP server calls another API, like your CRM, it needs its own separate token for that API. It may not forward the user's MCP token. The MCP security best practices explain why: passthrough breaks audit trails and lets one stolen token unlock several services.

Errors follow a simple pattern. A missing or invalid token gets a 401. A valid token without enough permission gets a 403.

Scopes and step-up authorization

Scopes are the specific permissions inside a token, such as files:read or files:write. Good scope design is one of the best security habits you can build in.

The spec favors least privilege. Clients "SHOULD" request only the scopes needed. If the user later tries something that needs more, the server responds with a 403 and an insufficient_scope error naming the missing scope. The app then runs a "step-up" sign-in to request it.

The security guide lists common mistakes to avoid:

• Publishing every possible scope up front.
• Using wildcard scopes like * or full-access.
• Bundling unrelated permissions to avoid future prompts.

For a business, this means a user can start with read-only access and approve write access only when a workflow needs it. Read more about why that matters in MCP security risks.

Token safety rules

A few more rules from the security considerations page are worth knowing:

• All authorization server endpoints "MUST be served over HTTPS."
• Redirect addresses must be either localhost or HTTPS.
• Authorization servers "SHOULD issue short-lived access tokens."
• For public clients, such as desktop apps, refresh tokens "MUST" be rotated.
• Clients and servers "MUST implement secure token storage."

Enterprise options: SSO and machine access

The core flow assumes each person approves each server. That works for consumers but scales poorly in a company. Two official extensions, both marked stable in the ext-auth repository, address this.

Enterprise-Managed Authorization

The Enterprise-Managed Authorization extension makes the company's identity provider the decision-maker. Its docs name Okta, Azure AD and corporate SSO systems as examples.

Here is how it works in plain terms. An employee signs in to the AI app with corporate SSO. The app asks the identity provider for a special grant called an ID-JAG. The provider checks company policy first, then the app trades that grant for an MCP access token.

The docs list the benefits: central policy, single sign-on, and "centralized revocation" that takes effect across all MCP clients. Support varies by client, and the extension is opt-in. Our MCP governance guide covers how this fits an IT access plan.

OAuth client credentials

The second extension covers machine-to-machine access, where no person is present. The core spec also notes that client_credentials clients, which act on their own behalf, may either step up or stop when they lack a scope.

What this means for your project

If you are buying or commissioning an MCP server, ask your developer these questions:

1. Do the remote endpoints use OAuth 2.1 per the 2026-07-28 spec?
2. Do you support Client ID Metadata Documents, not only Dynamic Client Registration?
3. Does the server validate the token audience and refuse passthrough?
4. What scopes exist, and what is the minimal starting set?
5. Will it work with our identity provider, and with the enterprise extension if we need it?

If you plan to build one yourself, how to build your first MCP server covers the basics.

Next step

Getting authorization right is the hardest part of most MCP builds. Our MCP development team can scope, build or review a server against the current spec.

Frequently asked questions