botminds.aiRequest a demo
Guide · Model Context Protocol

MCP authentication: how an AI assistant signs a person in to a remote MCP server.

The MCP specification builds sign-in from existing OAuth standards, so a server never sees a password and every call carries a token issued for that server alone.

A remote MCP server lets an AI model act on real systems, so the first question is whose permission it is using. This guide walks through the authorization flow the current specification (revision 2026-07-28) defines, the RFCs behind each step, how enterprises put their identity provider in charge, and the attacks the design is built to stop.

Updated · 16 sources

Read the guideHow Botminds does it
The standards behind MCP authentication
01
OAuth 2.1the base flow: authorization code with a proof key (PKCE)
IETF draft
02
Protected resource metadatathe MCP server says which authorization server issues its tokens
RFC 9728
03
Authorization server metadatawhere to send the person and where to fetch tokens
RFC 8414OIDC
04
Client registrationhow an assistant gets a client ID with no prior arrangement
CIMDRFC 7591
05
Resource indicatorseach token is bound to one MCP server
RFC 8707
06
Bearer tokens and scopesa token on every request; more scope only when needed
RFC 6750

How does MCP authentication work?

MCP authentication uses OAuth 2.1. When an assistant calls a remote MCP server without a token, the server answers 401 and points to its metadata; the assistant finds the authorization server, registers itself, and opens a browser where the person signs in and consents. The assistant then sends a token issued for that one server on every request, and the server checks it each time. Local servers over standard input and output take credentials from the environment instead.

Who is who

The four parties in MCP authentication, and what each holds.

The specification maps MCP onto OAuth’s roles. The most important consequence: the MCP server checks tokens but need not issue them, so a company’s own identity provider can sit in the middle.

One MCP requesta person’s permission, carried by an assistant to a server
The personthe resource owner who signs in and consents
MCP clientan OAuth client inside the assistant; usually public, with no secret to keep
MCP serveran OAuth resource server: it validates tokens on every request
Authorization serversigns the person in and issues tokens — the vendor’s or the company’s own
Remote server over HTTPfollows the OAuth flow in this guide
Local server over stdiotakes its credentials from the environment instead
Step by step

The MCP authentication flow, from first 401 to first tool call.

An assistant can connect to a server it has never seen, because each step tells it where to go next.

  1. Challenge

    The first call has no token. The server answers 401 with a link to its resource metadata and the scope it needs.

    401
  2. Discover

    The assistant reads which authorization server to use, then that server’s endpoints.

    RFC 9728RFC 8414
  3. Register

    It uses a pre-registered client ID or a client ID metadata document; dynamic registration remains only as a deprecated fallback.

    client ID
  4. Authorize

    A browser opens; the person signs in and consents. The request carries a PKCE challenge and names the target server; on return the client checks the iss value.

    PKCE S256resourceiss
  5. Call

    The token goes in the Authorization header of every request; the server checks it was issued for itself.

    Bearer
Step 1 — the server’s challenge
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer
  resource_metadata=
  "https://mcp.example.com/
   .well-known/oauth-protected-resource",
  scope="files:read"
Step 2 — its protected resource metadata
{
  "resource":
    "https://mcp.example.com",
  "authorization_servers": [
    "https://login.example.com"
  ],
  "scopes_supported":
    ["files:read", "files:write"]
}

Asking for more later. When a call needs a permission the token lacks, the server answers 403 with insufficient_scope and the scopes required. The assistant runs the flow again for just those — step-up authorization — so a token starts small.

Spec revisions

How MCP authentication changed from 2024 to 2026.

The authorization design was rewritten twice in its first year and tightened twice since. Older blog posts and server code often describe a superseded revision.

  1. Nov 2024LaunchRevision 2024-11-05 defines no authorization framework.
  2. Mar 2025OAuth 2.1 arrivesRevision 2025-03-26 adds an authorization framework; PKCE required; by default the MCP server is also its own authorization server, with delegation to a third party optional.
  3. Jun 2025Resource serversRevision 2025-06-18: servers become OAuth resource servers with RFC 9728 metadata; tokens must name their server (RFC 8707).
  4. Nov 2025Registration and scopesRevision 2025-11-25: client ID metadata documents recommended; OpenID Connect discovery; scope step-up.
  5. Jun 2026Enterprise-managedThe Enterprise-Managed Authorization extension lets the company’s identity provider grant access to MCP servers; declared stable.
  6. Jul 2026Issuer checksRevision 2026-07-28 deprecates dynamic registration, asks for iss in authorization responses (RFC 9207) and binds client credentials to their issuer.
Client registration

How an assistant gets a client ID for an MCP server it has never met.

OAuth assumes the client is registered in advance. MCP assistants connect to servers chosen by their users, so the specification ranks four ways to get a client ID.

What does the assistant already have with this authorization server?

1 · A prior arrangementPre-registration. Use the client ID the two already agreed.
2 · Nothing; server supports CIMDClient ID metadata document. The client ID is an HTTPS URL to a JSON file naming the app and its redirect addresses.
3 · Nothing; server takes registrationsDynamic client registration (RFC 7591) — deprecated in revision 2026-07-28, kept for authorization servers without CIMD.
4 · None of theseAsk the person to enter client details they registered themselves.

What to check on a client ID metadata document. The authorization server fetches a URL supplied by a stranger, so the specification warns of server-side request forgery, and of apps that copy a real app’s document and redirect to localhost. Show the redirect host on the consent screen and consider an allow-list of trusted domains. Whatever the method, the client keeps its credentials keyed to the issuing authorization server and registers again if that server changes.

Identity provider in charge

MCP authentication in the enterprise: who decides which servers people use.

The standard flow asks each person to consent to each server. Companies want the identity provider they already run to make that call — and many servers on the internet still ask for nothing at all.

the core flow

Per-person consent

Each person signs in and approves each assistant–server pair on a consent screen.

  • Works with any OAuth server
  • The person decides, server by server
  • A consent screen for each new server
  • Admins see the result afterwards
extension, stable 2026

Enterprise-managed

An administrator enables MCP servers in the identity provider by group and role; at sign-in the assistant gets a signed grant and exchanges it for tokens.

  • The identity provider decides
  • Policy by group, role and conditional access
  • No per-server consent screens
  • Revoke in one place
The personWho approves accessThe company’s identity provider
An authorization codeWhat the assistant presentsAn identity assertion grant (ID-JAG)
Consent for each serverFirst-day experienceServers ready at first sign-in
1,862
MCP servers found exposed to the internet in a July 2025 scan
Knostic, security vendor, 2025
119 of 119
servers in the sample the researchers verified listed their tools to a caller with no credentials
Knostic, security vendor, 2025
Security

Nine attacks MCP authentication is designed to stop.

Each rule in the specification answers a specific attack. When reviewing an MCP server or client, check them one by one.

The attack, and the rule that answers it
  • Token reuse across servicesTokens name their server (RFC 8707), and servers refuse tokens issued for anything else.
  • Token passthroughA server never forwards the token it received; calls to other APIs use separate tokens.
  • Stolen authorization codesPKCE with S256, so only the client that started the flow can redeem the code.
  • Confused deputyA proxy server with one static client ID must get each client’s consent before forwarding.
  • Open redirectsRedirect addresses registered in advance and matched exactly; state checked on return.
  • State handle hijackingServers verify every request and never treat a state handle — or, in revisions before July 2026, a session ID — as proof of identity.
  • Authorization server mix-upThe authorization server names itself in iss (RFC 9207); the client checks it before redeeming the code.
  • Forged discovery URLsClients should block internal addresses and require HTTPS while fetching metadata.
  • Over-broad tokensStart with minimal scopes and add more through step-up, so a stolen token opens little.
On Botminds

How the Botminds MCP server applies MCP authentication.

The Botminds MCP server holds no identity of its own: every request carries a valid token for one person and is handled as that person, with that person’s role.

What the specification asksOn Botminds
DiscoveryProtected resource metadata (RFC 9728)The assistant finds where to sign in from the server link
RegistrationPre-registration or CIMD; dynamic registration deprecated but allowedAssistants register themselves as public clients — no client secret to steal
Sign-inAuthorization code with PKCEAuthorization code with a proof key, through the normal Botminds sign-in and a consent card naming the app
AudienceTokens issued for this server onlyEach token names the MCP server and carries the MCP scope; tokens for anything else, including a browser session, are refused
ValidationCheck every requestSignature, expiry and audience checked on every call; the server is stateless and fails closed
Revoking accessOutside the specificationA list of connected AI clients to disconnect; suspending a person ends all their connections
RecordsOutside the specificationRegistration, consent, token issue and disconnect logged — with IDs, never tokens

Go further. The full design: MCP for the enterprise. Connecting an assistant, hands-on: the Academy lesson on MCP integration. What the protocol is for: MCP vs API.

Questions people ask

MCP authentication: common questions.

The technology behind itMCPThe Model Context Protocol, both ways
How does MCP authentication work?

MCP authentication uses OAuth 2.1. The server answers an unauthenticated call with 401 and a metadata link; the assistant discovers the authorization server, registers, and sends the person to sign in with PKCE. It then sends a token issued for that server on every request.

What is the difference between authentication and authorization in MCP?

Authentication proves who the person is; it happens at the authorization server, often the company’s identity provider. Authorization decides what the token allows; the specification covers it with OAuth scopes, and the server behind the tools still checks the person’s permissions.

Does MCP use OAuth 2.1?

Yes. Since the March 2025 revision the specification bases authorization on the OAuth 2.1 draft, with PKCE required, and adds protected resource metadata, authorization server discovery and resource indicators.

What is CIMD in MCP OAuth?

A client ID metadata document: the assistant uses an HTTPS URL as its client ID, and that URL serves JSON naming the app and its redirect addresses. Since November 2025 it is the recommended way to register when client and server have never met, and since revision 2026-07-28 it replaces dynamic registration.

What is dynamic client registration in MCP?

RFC 7591 lets an assistant register itself with an authorization server and receive a client ID without human help. The current specification (2026-07-28) deprecates it in favour of client ID metadata documents and keeps it only for authorization servers that do not support them.

Do local MCP servers need OAuth?

No. Servers that run on the same machine over standard input and output should take credentials from the environment. The OAuth flow is for remote servers over HTTP.

What is protected resource metadata (RFC 9728)?

A JSON document a server publishes, usually under /.well-known/oauth-protected-resource, naming the authorization servers that issue its tokens and the scopes it supports. MCP servers must publish it, and clients must use it to find where to sign in.

How can a company control which MCP servers employees use?

With the Enterprise-Managed Authorization extension, declared stable in June 2026: administrators enable servers in the identity provider by group and role, and assistants exchange a signed grant from the identity provider for tokens.

Why is token passthrough forbidden in MCP?

If a server forwarded the token it received to another API, it would bypass that API’s audience checks, blur the audit trail and let a stolen token travel. The specification requires servers to accept only their own tokens and use separate ones downstream.

Sources
  1. MCP specification (2026-07-28): authorizationmodelcontextprotocol.io
  2. MCP specification (2026-07-28): client registrationmodelcontextprotocol.io
  3. MCP specification (2026-07-28): security best practicesmodelcontextprotocol.io
  4. MCP specification: key changes in 2026-07-28modelcontextprotocol.io
  5. MCP specification: key changes in 2025-03-26modelcontextprotocol.io
  6. MCP specification: key changes in 2025-06-18modelcontextprotocol.io
  7. MCP specification: key changes in 2025-11-25modelcontextprotocol.io
  8. IETF draft: The OAuth 2.1 Authorization Framework (draft 13)datatracker.ietf.org
  9. RFC 9728: OAuth 2.0 Protected Resource Metadatadatatracker.ietf.org
  10. RFC 8414: OAuth 2.0 Authorization Server Metadatadatatracker.ietf.org
  11. RFC 7591: OAuth 2.0 Dynamic Client Registration Protocoldatatracker.ietf.org
  12. RFC 8707: Resource Indicators for OAuth 2.0datatracker.ietf.org
  13. RFC 9207: OAuth 2.0 Authorization Server Issuer Identificationdatatracker.ietf.org
  14. IETF draft: OAuth Client ID Metadata Documentdatatracker.ietf.org
  15. MCP blog: Enterprise-Managed Authorization (June 2026)blog.modelcontextprotocol.io
  16. Knostic: Mapping MCP servers exposed to the internet (July 2025)knostic.ai
Read next
MCP vs APIHow the Model Context Protocol relates to the APIs you already haveA2A vs MCPGoogle’s Agent2Agent protocol and the Model Context Protocol, side by sideAI agent security best practicesIdentity, least privilege, approvals, containment and audit for agentsAll guidesEvery explainer, by topic

See it on
your own work.

Bring one process and its documents. We’ll show you the agents, the controls and the record, running on your data.

Book a demoMCP