Home Glossary
HomeGlossaryOAuth in MCP
MCP Glossary

OAuth in MCP

TL;DR

OAuth in MCP is the standardized authorization flow defined by the MCP specification for remote servers. Based on OAuth 2.1, it lets MCP servers securely authenticate users without handling credentials directly. The flow was introduced in spec revision 2025-03-26 to support remote MCP deployments.

In depth

When MCP expanded beyond local stdio servers to remote HTTP deployments, it needed a standard authentication mechanism. The spec adopted OAuth 2.1 (the modern consolidation of OAuth 2.0 + PKCE + refresh tokens + best practices) and defined how clients and servers negotiate tokens.

The flow: the user tries to use a remote MCP. The client opens a browser to the server's OAuth authorization endpoint. The user logs in with their real credentials (via the SaaS, not the MCP). The server redirects back with an authorization code. The client exchanges the code for an access token + refresh token. Subsequent `Mcp-Session-Id` requests include the token as a Bearer header.

Tokens are refreshed automatically — access tokens are typically short-lived (1 hour); refresh tokens are longer (30+ days) and stay in the host's secure store. The user can revoke at the provider side and the agent loses access immediately.

OAuth in MCP also supports Dynamic Client Registration (RFC 7591), so MCP clients don't need manual registration at each provider — they register themselves at first use.

Code example

// Step 1: Client redirects user to OAuth authorize endpoint
// https://mcp.example.com/oauth/authorize?response_type=code
//   &client_id=abc&redirect_uri=app://callback&scope=read+write&code_challenge=...

// Step 2: User authorizes, gets redirected back with code
// app://callback?code=xyz

// Step 3: Client exchanges code for tokens
POST /oauth/token
{
  "grant_type": "authorization_code",
  "code": "xyz",
  "code_verifier": "...",
  "client_id": "abc"
}

// Response
{
  "access_token": "at_...",
  "refresh_token": "rt_...",
  "token_type": "Bearer",
  "expires_in": 3600
}

// Step 4: Use access token in all MCP requests
POST /mcp HTTP/1.1
Authorization: Bearer at_...
Mcp-Session-Id: sess_...

Examples

  • 1
    Claude Desktop authorizing a remote Notion MCP via browser OAuth
  • 2
    Cursor connecting to a remote Linear MCP with OAuth + token refresh
  • 3
    A custom agent using PKCE to avoid exposing the client secret
  • 4
    Token revocation: user clicks 'disconnect' and the agent loses access
  • 5
    Dynamic client registration at a new enterprise MCP deployment

What it's NOT

  • ✗OAuth in MCP is NOT optional for remote servers — it's the recommended auth mechanism.
  • ✗OAuth tokens are NOT passed to the LLM — they stay in the client's secure storage.
  • ✗OAuth is NOT used for stdio servers — they rely on environment variables or subprocess permissions.
  • ✗OAuth in MCP is NOT a custom flavor — it's standard OAuth 2.1 with MCP-specific metadata.

Related terms

MCP TransportMCP SessionHTTP / Streamable TransportJSON-RPC 2.0

See also

  • MCP OAuth Spec
  • OAuth 2.1

Frequently asked questions

Does every MCP server need OAuth?

Only remote ones with user-delegated actions. Local stdio servers use subprocess permissions instead.

How are tokens stored?

In the host's secure storage (macOS Keychain, Windows DPAPI, Linux libsecret). Never in plain files.

Can I revoke access?

Yes — revoke the OAuth grant at the provider. The MCP client's next token refresh fails, effectively disconnecting.

Build with MCP

Browse 300+ MCP servers, explore recipes, or continue learning the MCP vocabulary.

Browse MarketplaceAll terms