Skip to content

New to MCP?

Lock down MCP connections with OAuth 2.1 so agents get only the access they need

AI systems are moving beyond chatbots to agents that act in the real world. They handle sensitive data and run complex workflows. As they grow, they need a secure, standard way to connect. The Model Context Protocol (MCP) provides that standard. It defines how AI applications safely discover and use external tools and data.

MCP ServerChat interfaceData and file systemsDevelopment toolsProductivity toolsIDEs and code editorsOther AI applicationsScalekitOAuth 2.1 server

MCP incorporates OAuth 2.1 authorization mechanisms at the transport level. This enables MCP clients to make secure requests to restricted MCP servers on behalf of resource owners.

FeaturesBenefit
Industry standardWell-established authorization framework with extensive tooling and ecosystem support
Security best practicesIncorporates improvements over OAuth 2.0, removing deprecated flows and enforcing security measures like PKCE
Multiple grant typesSupports different use cases: Authorization code for human user scenarios and Client credentials for machine-to-machine integrations
Ecosystem compatibilityIntegrates with existing identity providers and authorization servers
MCP authorization specification overview

This authorization mechanism is based on established specifications listed below, but implements a selected subset of their features to ensure security and interoperability while maintaining simplicity:

  • OAuth 2.1
  • OAuth 2.0 Authorization Server Metadata (RFC8414)
  • OAuth 2.0 Dynamic Client Registration Protocol (RFC7591)
  • OAuth 2.0 Protected Resource Metadata (RFC9728)
Quick reference: High-level flow

This simplified diagram shows the key actors and main interactions. Use this for quick reference while scrolling through the detailed flow below.

MCP ClientMCP ServerAuthorization ServerUser Request resource (unauthorized) 401 + Auth server info Discover capabilities Register client Request authorization Authenticate & consent Access token Request with token Protected resource Refresh token (when expired)

Here’s the complete end-to-end authorization flow showing all phases from discovery to token refresh in a single sequence diagram:

MCP ClientMCP ServerAuthorization ServerUserDiscovery phaseDynamic client registrationAuthorization code flowAccess phaseToken refresh (when needed) POST /mcp/tools/weather(No Authorization Header) 401 UnauthorizedWWW-Authenticate: resource_metadata="..." GET /.well-known/oauth-protected-resource Resource metadata with authorization_servers GET /.well-known/oauth-authorization-server Authorization server metadata(endpoints, supported flows, etc.) POST /oauth2/register(client metadata) client_id, client_secret(if confidential client) Redirect to authorization endpointwith PKCE challenge GET /oauth2/authorize(user authenticates & grants consent) Redirect with authorization code Authorization code returned POST /oauth2/token(code + PKCE verifier) access_token, refresh_tokenwith scopes (e.g., "mcp:tools:weather") POST /mcp/tools/weatherAuthorization: Bearer <access_token> Validate token and check scopes("mcp:tools:weather") If token valid: Process weather request 200 OKWeather data response If invalid: 401/403 ErrorToken invalid or insufficient scope POST /oauth2/token(grant_type=refresh_token) New access_token, refresh_token
Discovery phase
  1. MCP client attempts to access a protected resource without credentials
  2. MCP server responds with 401 Unauthorized and includes authorization metadata in the WWW-Authenticate header
  3. Client retrieves resource metadata to identify authorization servers
  4. Client discovers authorization server capabilities through the metadata endpoint
Dynamic client registration
  1. Client submits registration request with metadata (redirect URIs, application info)
  2. Authorization server validates the request and issues client credentials
  3. Client stores credentials securely for subsequent authorization requests
Authorization code flow
  1. Client generates PKCE code verifier and challenge
  2. Client redirects user to authorization server with PKCE challenge
  3. User authenticates and grants consent for requested scopes
  4. Authorization server redirects back with authorization code
  5. Client exchanges code and PKCE verifier for access token
  6. Authorization server validates PKCE and issues tokens with granted scopes
Access phase
  1. Client includes access token in the Authorization header
  2. MCP server validates the token signature and expiration
  3. Server checks if token scopes match the required permissions
  4. If token is valid and scope is sufficient: Server processes the request and returns 200 OK with the requested data
  5. If token is invalid or scope is insufficient: Server returns 401 Unauthorized or 403 Forbidden error
Token refresh (when needed)
  1. Client detects token expiration (through 401 response or token expiry time)
  2. Client sends refresh token request to authorization server
  3. Authorization server validates refresh token and issues new access tokens
  4. Client updates stored tokens and retries the original request

MCP OAuth 2.1 provides secure, standardized authorization for AI agents accessing protected resources. The flow establishes trust, authenticates users, authorizes access, and maintains security throughout the session lifecycle by building each phase on the previous one.

Original diagram reference

For reference, here’s the complete flow diagram showing all phases and interactions in a traditional sequence diagram format:

MCP OAuth 2.1 Authorization Flow