Skip to main content
Use OAuth for MCP servers that require user consent, like Gmail, Google Calendar, or other services with delegated access.

OAuth Flow

The OAuth flow is triggered when you call an MCP server that requires user authentication.
1

Request Without Token

The SDK calls the MCP server. If no valid token exists, the server returns 401 with a WWW-Authenticate header.
2

Protected Resource Discovery

The SDK fetches /.well-known/oauth-protected-resource (RFC 9728) to discover the authorization server and supported scopes.
3

AuthenticationError

The SDK raises AuthenticationError containing a connect_url—the full OAuth authorization URL.
4

Browser Interaction

Your app opens the user’s browser to the connect_url. The user logs in and grants (or denies) the requested scopes.
5

Token Exchange

Upon approval, the authorization server exchanges the authorization code for tokens using PKCE. DAuth stores the tokens server-side.
6

Retry Request

The user returns to your app and triggers a retry. The SDK re-sends the request, now with valid credentials.
7

Authenticated Requests

The access token is automatically included for subsequent requests to the MCP server.
8

Token Refresh

If the access token expires, DAuth automatically uses the refresh token to obtain a new access token.

How It Works

OAuth Retry Helper

Handle the OAuth flow with a retry wrapper:

Full Example: DedalusRunner

Full Example: Raw Client

For single requests with full control over API response:

Environment

No OAuth credentials needed client-side. The MCP server handles OAuth configuration, and DAuth manages token storage.

When to Use

OAuth works for:
  • User-facing applications
  • Delegated access (acting on behalf of users)
  • Services like Gmail, Google Calendar, Linear, GitHub
Use Bearer Auth instead for:
  • API keys and service tokens
  • Backend integrations without user context
  • Service-to-service calls
Last modified on August 9, 2026