How does MCP authentication work?

The Model Context Protocol (MCP) lets AI apps such as Claude, ChatGPT and code editors call tools and read data on remote servers. As soon as a server holds company data, it needs to know who is calling and what they may do. That is MCP authentication (who you are) and MCP authorization (what the token lets you do).

This page describes how the MCP authorization specification (revision 2026-07-28, the latest at the time of writing) says it should work, in plain terms.

Who are the parties in MCP authorization?

The spec maps MCP onto standard OAuth roles:

• MCP server: an OAuth resource server. It holds the tools and data and accepts access tokens.
• MCP client: an OAuth client inside the AI app. It makes requests on behalf of a person.
• Authorization server: signs the person in and issues tokens. It can be part of the MCP server or a separate identity service.

Authorization is optional in MCP. Servers that use an HTTP transport and support it should follow the spec. Local servers that talk over standard input and output (stdio) should not use this flow and should read credentials from their environment.

How does remote MCP sign-in work, step by step?

The spec’s flow, simplified:

1. The client calls the server without a token. The server replies 401 Unauthorized with a header pointing to its protected resource metadata.
2. The client reads the protected resource metadata (RFC 9728). This document lists the authorization server or servers for this MCP server. If the header is missing, the client tries well-known URLs.
3. The client discovers the authorization server through OAuth authorization server metadata or OpenID Connect discovery. Clients must support both.
4. The client gets a client ID, using one of the registration options below.
5. The client starts sign-in with PKCE. It opens a browser with a code challenge and a resource parameter naming the MCP server.
6. The person signs in and approves. The authorization server redirects back with a code and its issuer name; the client checks the issuer matches the one it expected.
7. The client exchanges the code for tokens, sending the PKCE verifier and the resource parameter again.
8. The client calls the MCP server with the access token in the Authorization header on every request, never in the URL.

What are PKCE and resource indicators, and why do they matter?

• PKCE (Proof Key for Code Exchange) is a secret pair the client creates for each sign-in. Only the client that started the sign-in can turn the code into a token, which stops stolen codes being used. MCP clients must use PKCE, use the S256 method when they can, and refuse to continue if the authorization server does not advertise PKCE support.
• Resource indicators (RFC 8707) let the client say which server the token is for. MCP clients must send the resource parameter in both the authorization and token requests, using the MCP server’s canonical URL.
• Audience checks are the other half. MCP servers must reject any token that was not issued specifically for them.

Together these mean a token for one MCP server cannot be replayed against another.

How do MCP clients register with a server?

A client needs a client ID before it can sign in. The spec defines three ways, in this order of preference:

Method	When it fits	Status in the spec
Pre-registration	Client and server already know each other; an admin created a client ID and secret	Supported; clients should offer a way to enter static credentials
Client ID Metadata Documents	Client and server have no prior relationship (the common case)	Recommended (SHOULD)
Dynamic client registration	Older servers that do not support metadata documents	Deprecated, kept for backwards compatibility

With a Client ID Metadata Document, the client ID is an HTTPS URL that serves a small JSON file with the client’s name and allowed redirect URLs. The authorization server fetches it and checks the redirect URL matches.

API keys vs OAuth for MCP: which should you use?

	API key in a header	OAuth sign-in (per the MCP spec)
Who it identifies	Usually a project or service	A specific person
Setup	Paste a key into the client	Sign in and approve in a browser
Permissions	Whatever the key allows	Scopes the person approved, within their own access
Revocation	Revoke or rotate the key	Revoke the app or the person’s grant
Risk if leaked	Anyone with the key has its access until revoked	Tokens bound to one server, ideally short-lived
Best for	Scripts, server-to-server calls, CI	People using AI apps like Claude or ChatGPT

Both are valid. The mistake is using one shared key for many people, because the server can no longer tell who did what.

How do scopes work in MCP?

Scopes name what a token may do, such as reading files or writing them. The spec asks clients to follow least privilege:

• The server’s 401 or 403 response can include the scopes needed for this request. Clients should request those first.
• If none are given, clients use the minimal set the server lists in its metadata.
• When a later action needs more, the server replies 403 with “insufficient_scope”, and the client asks the person to approve the extra scopes (a step-up). The client should keep previously granted scopes.

What are the main MCP security risks?

The spec’s security considerations and security best practices cover these in depth. The ones that matter most for teams:

• Confused deputy. A proxy MCP server that uses one static client ID with a third-party API can be tricked into granting access without the person’s consent. The spec requires such servers to get consent for each dynamically registered client.
• Token passthrough. Forwarding the incoming token to another API is forbidden. Upstream calls need their own tokens.
• Token theft. Tokens must be stored securely; authorization servers should issue short-lived access tokens and must rotate refresh tokens for public clients.
• Over-broad scopes. Asking for everything up front makes a stolen token far more damaging.
• Tool poisoning. A tool’s description is text the model reads. The main MCP spec says tool descriptions and annotations should be treated as untrusted unless they come from a trusted server, and hosts must get consent before invoking tools. Only connect servers you trust.

MCP authentication checklist

1. Serve every authorization endpoint over HTTPS.
2. Publish protected resource metadata and return it in the 401 response.
3. Require PKCE with S256.
4. Validate the token audience on every request; never accept or forward other tokens.
5. Support Client ID Metadata Documents; keep dynamic registration only if you must.
6. Start with minimal scopes and use step-up for more.
7. Issue short-lived access tokens and rotate refresh tokens.
8. Let people and admins see and revoke connected apps.
9. Require human approval for write and destructive tools. See human in the loop AI.
10. Log which app and which person made each call.

How promptev handles MCP authentication

• The workspace MCP at https://api.promptev.ai/mcp uses sign-in with your promptev account; you pick one workspace and the permissions to grant, and the app then works as you, with your role.
• Apps may connect unless an admin turns off “Allow apps to connect”, and only builders (editors, admins and owners) can connect.
• Each person can sign an app out under Profile, in “Where you’re signed in”; turning off, removing or demoting a person signs their apps out, and the audit trail shows which app acted.
• The project MCP uses a project API key; keys belong to one project and can expire or be revoked.
• Tool approvals appear right in MCP clients that can show them. See how this fits with governance.