--- title: "MCP Authentication: How AI Agents Sign In Safely" description: "How MCP authentication works: OAuth 2.1, protected resource metadata, client registration, PKCE and audience-bound tokens, and the mistakes the spec forbids." url: https://thedrive.ai/blog/mcp-authentication-for-ai-agents published: 2026-10-29 updated: 2026-10-29 tags: ["mcp", "mcp authentication", "oauth", "ai agents", "security", "developers"] author: "Bigyan Karki" publisher: The Drive AI --- # MCP Authentication: How AI Agents Sign In Safely > **TL;DR:** A remote MCP server authenticates with OAuth 2.1. The server answers an unsigned request with a 401 that points to its protected resource metadata; the client finds the authorization server there, registers, sends the person to sign in with PKCE, and gets an access token bound to that one server. A local server that runs over standard input and output skips all of this and reads its credentials from the environment. The two rules that matter most: a server accepts only tokens issued for it, and it never forwards a client's token to another API. Disclosure: The Drive AI publishes this guide and runs a remote MCP server that people connect to Claude, ChatGPT and other clients. The specification quoted below is the MCP authorization spec, revision 2026-07-28, as published at [modelcontextprotocol.io](https://modelcontextprotocol.io/specification/latest/basic/authorization) and read in October 2026. ## How does MCP authentication work? MCP authentication is standard OAuth applied to the Model Context Protocol. The MCP server is an OAuth resource server, the assistant (Claude, ChatGPT, Cursor, an agent you wrote) is the OAuth client, and a separate authorization server signs the person in and issues tokens. The spec defines this flow for HTTP transports only, and makes authorization optional: a server that needs no sign-in can skip it. The flow, step by step: 1. The client calls the MCP server without a token and gets `401 Unauthorized` with a `WWW-Authenticate` header naming the server's **protected resource metadata** (RFC 9728). 2. The client fetches that document. Its `authorization_servers` field says who issues tokens for this server. 3. The client fetches the authorization server's metadata (RFC 8414 or OpenID Connect Discovery) to learn its endpoints and what it supports. 4. The client gets a client ID: pre-registered, a **Client ID Metadata Document**, or **Dynamic Client Registration**. 5. The client opens the browser to the authorization endpoint with a PKCE challenge and a `resource` parameter naming the MCP server. The person signs in and agrees. 6. The client trades the returned code, plus the PKCE verifier, for an access token (and usually a refresh token). 7. Every MCP request carries `Authorization: Bearer `. The spec forbids putting the token in a query string. If you are new to the protocol itself, [MCP vs API](https://thedrive.ai/blog/mcp-vs-api) covers what an MCP server is and how it differs from a plain REST API. ## Do local MCP servers need authentication? Not through OAuth. The spec says implementations using the STDIO transport "SHOULD NOT follow this specification, and instead retrieve credentials from the environment." A local server runs as a child process of the client, on your machine, so it usually reads an API key or a token from an environment variable or a config file. That shifts the risk rather than removing it: the MCP security best practices warn that a local server runs with the client's privileges. A remote server is the opposite trade. Nothing runs on your machine, but anyone on the internet can reach it, so it has to prove who is calling. ## What does the MCP authorization spec require? The 2026-07-28 revision rests on six requirements, each closing a specific hole. | Requirement | What it means | Why it exists | |---|---|---| | OAuth 2.1 | Authorization servers MUST implement OAuth 2.1 | One current, hardened version of OAuth instead of many variants | | Protected resource metadata | MCP servers MUST publish RFC 9728 metadata naming their authorization server | A client can discover where to sign in from the server URL alone | | Client registration | Client ID Metadata Documents SHOULD be supported; Dynamic Client Registration MAY be, and is now deprecated | Clients and servers that have never met can still connect | | PKCE | Clients MUST use PKCE, with `S256` when they can, and MUST refuse a server whose metadata does not list it | A stolen authorization code is useless without the verifier | | Resource indicators | Clients MUST send `resource` (RFC 8707) in authorization and token requests | The token is bound to one MCP server, its audience | | Audience validation | Servers MUST accept only tokens issued for them, and MUST NOT accept or transit any other tokens | A token for one service cannot be replayed at another | The registration row is the recent change. Earlier revisions leaned on Dynamic Client Registration, where each client POSTs to a `/register` endpoint. In 2026-07-28 the preferred route is a Client ID Metadata Document: the client's ID is an HTTPS URL serving its name and redirect URIs, which the authorization server fetches. The revision also has clients check the `iss` value in the authorization response (RFC 9207), so a malicious authorization server cannot collect a code meant for an honest one. ## Should an MCP server use API keys or OAuth? Use OAuth for a remote server that acts for people, and an API key only for a local server or a machine-to-machine job you control. The difference is who holds the credential and what it can do. | | API key | OAuth | |---|---|---| | Who creates it | The person, by hand, in a settings page | The authorization server, after the person signs in and agrees | | Where it lives | A config file or environment variable | The client's token store | | Lifetime | Until someone revokes it | Short-lived access token, renewed with a refresh token | | Scope | Often the whole account | The scopes the person agreed to | | Bound to one server | No | Yes, through the `resource` audience | | Fits | Local STDIO servers, scripts, CI | Remote servers used from Claude, ChatGPT and other hosts | ## How should scopes work for an AI agent? Ask for the least the agent needs, and let the server ask for more when an operation requires it. The spec's scope guidance follows least privilege: a server SHOULD name the scopes it requires in the `WWW-Authenticate` header, and when a call needs more, it answers `403` with `error="insufficient_scope"` and the scopes required. The client then runs a step-up authorization for the union of what it had and what it now needs. The MCP security best practices list the common mistakes: publishing every possible scope, omnibus scopes such as `*` or `full-access`, and bundling unrelated privileges to avoid a future prompt. For a file agent, a useful split is reading, changing files, and changing who can see them: each carries a different risk if a token leaks. ## Where are MCP tokens stored, and how do they refresh? Somewhere the person's other software cannot read, and for as short a time as possible. The spec says clients and servers MUST store tokens securely, authorization servers SHOULD issue short-lived access tokens, and for public clients they MUST rotate refresh tokens: each refresh returns a new refresh token and retires the old one, so a stolen one stops working after its first legitimate use. In practice: keep tokens in the operating system's keychain, a file only the user can read, or encrypted at rest on a server. Refresh shortly before the access token expires, not after a 401, so a long task does not stop halfway. And let the person end a connection from the service's own settings, not only from the client. ## What goes wrong with MCP authentication? Two failures get their own sections in the spec's security pages. **Token passthrough.** An MCP server receives a token from the client and forwards it, unchanged, to a downstream API. The spec states that the server "MUST NOT pass through the token it received from the MCP client". If the server calls another API, it acts as that API's OAuth client with a separate token. Passthrough breaks audit trails (the downstream service cannot tell who really called), bypasses the server's own checks, and lets a stolen token use the server as a proxy. **The confused deputy.** This hits MCP servers that proxy a third-party API with one static client ID while letting MCP clients register dynamically. The person consents once; the third-party authorization server sets a consent cookie; later an attacker registers a client with their own redirect URI and sends the person a link. The cookie skips the consent screen and the code goes to the attacker. The fix the spec requires: the MCP server shows its own consent screen, naming the requesting client, for each client, before forwarding to the third party. ## How does The Drive AI's MCP server authenticate? The Drive AI is its own authorization server, and its remote MCP server at `https://mcp.thedrive.ai/mcp` follows the flow above. An unsigned request gets a 401 pointing to `/.well-known/oauth-protected-resource/mcp`, and the authorization server metadata advertises `S256` PKCE, Client ID Metadata Documents, a registration endpoint and the `iss` response parameter (checked October 29, 2026). The setup for each client is on the [MCP server for Google Drive](https://thedrive.ai/mcp), OneDrive, SharePoint and Dropbox page. What happens when someone connects from Claude or ChatGPT: - **Sign-in is The Drive AI's own.** The person signs in on thedrive.ai with whatever method their account uses: Google, Microsoft, Apple or email. A person already signed in still has to choose "Continue" as their address or pick a different account, so an open session never authorizes a host silently. The connector also shows its own consent screen naming the host, the per-client consent the confused deputy section calls for. - **The agent acts with the person's own permissions.** Tokens name the person, and every tool call runs as them: it sees what they can see and changes what they can change. - **Short, audience-bound tokens.** Access tokens are signed JWTs with the audience `mcp`, last an hour and are verified against published keys. The connector refreshes them two minutes before they expire, and each refresh token works once. - **Scopes on every grant.** `read`, `write`, `share` and `ask`. A chat host gets all four; an agent connecting on its own asks for what it needs. The scopes are checked against the stored grant on each call, so narrowing or ending a connection in Settings → MCP takes effect on the next call, not at token expiry. - **Changes are previewed.** Sign-in decides who is calling. Changes are proposed first, larger ones ask for confirmation, and an applied change can be undone. For a wider look at how other servers handle sign-in and permissions, see this comparison of [file access for AI agents](https://thedrive.ai/blog/best-mcp-servers-google-drive-onedrive-dropbox-2026) across ten MCP servers. ## Frequently Asked Questions ### Is OAuth required for MCP servers? No. The spec makes authorization optional. A remote HTTP server that requires sign-in SHOULD follow the OAuth 2.1 flow the spec defines. A local server over standard input and output SHOULD NOT, and reads its credentials from the environment instead. Public, read-only servers with no user data can skip sign-in entirely. ### What is protected resource metadata in MCP? It is a JSON document, defined by RFC 9728, that an MCP server publishes to say which authorization server issues its tokens. The server points to it in the `WWW-Authenticate` header of a 401, or serves it at a well-known path. Clients MUST use it to discover where to sign in. ### Why does MCP require PKCE? PKCE stops an intercepted authorization code from being redeemed. The client creates a secret verifier, sends only its hash with the authorization request, and proves the verifier when it trades the code for tokens. The spec requires `S256` where possible and tells clients to refuse servers that do not advertise PKCE support. ### Can an MCP server use my token to call other APIs? It must not forward the token it received. The spec forbids token passthrough: a server accepts only tokens issued for itself, and if it calls another API it does so as that API's OAuth client with a separate token. A server that forwards your token breaks audit trails and lets a stolen token travel further. --- To see the flow end to end, connect The Drive AI's [MCP server](https://thedrive.ai/mcp) to Claude or ChatGPT, sign in with your own account, then open Settings → MCP: every connection is listed with its scopes, and you can end any of them there.