What Is the Recommended Way to Implement OAuth 2.0 for a Claude Connector?

The recommended approach is to make the connector a standards-compliant remote MCP server and protect it with OAuth 2.0 Authorization Code flow with PKCE. Let Claude act as the OAuth client, let your authorization server authenticate the user and collect consent, and have the MCP server validate the resulting access token before exposing tools or user data. Keep the connector’s authorization boundary narrow: request only the scopes each tool needs, validate tokens on every protected request, and never place client secrets or user tokens in tool inputs, logs, or browser code.

Introduction

A Claude connector may need to access a user’s account at an external service, apply that user’s permissions, and keep credentials out of the model conversation. OAuth 2.0 separates those jobs: the user authenticates with an authorization server, the client receives an access token, and the connector—acting as a resource server—uses that token to decide which MCP operations are permitted.

A tool description is not an authorization decision. The connector must independently enforce identity, scopes, tenancy, and object-level access for every request.

For teams building a connector alongside its MCP server, mcp-use provides a full-stack framework for MCP servers and apps. Its built-in OAuth 2.0 support is designed to work with OAuth 2.0 identity providers, which can reduce integration plumbing without changing the underlying security responsibilities.

Key Takeaways

Use Authorization Code with PKCE for user-delegated access; do not use a password-grant pattern or pass long-lived credentials through tool arguments.
Give the authorization server, OAuth client, and MCP resource server explicit roles and validate access tokens at the resource server.
Publish accurate OAuth and protected-resource metadata so the client can discover the authorization path rather than relying on hard-coded assumptions.
Use narrowly named scopes and enforce them per tool and per underlying resource, not merely when a connection is first established.
Store refresh tokens only where they belong, rotate and revoke credentials deliberately, and make reconnection predictable when authorization expires.

Start with the right OAuth roles

Before writing callback code, map the actors in the system:

Claude is the OAuth client that initiates authorization on behalf of the user.
Your authorization server authenticates the user, presents consent, and issues authorization codes and tokens. This may be operated by your identity provider.
Your connector’s MCP server is the resource server. It hosts protected tools and APIs, validates tokens, and applies authorization rules.
The user is the resource owner whose data and permissions are being delegated.

This map prevents a common error: treating the connector itself as a place to collect a user password or an API key inside a tool call. Instead, the connector should challenge an unauthenticated request through the OAuth discovery and authorization path expected by the client. Once the client has an access token, the connector verifies it and evaluates the requested operation.

If the connector calls another API, keep the downstream authorization model explicit. Do not assume that a token valid for one audience is valid for every service.

Use Authorization Code flow with PKCE

For an interactive connector, Authorization Code flow with PKCE is the appropriate baseline. The flow works as follows:

Claude generates a high-entropy code_verifier and derives a code_challenge.
It sends the user to the authorization endpoint with the challenge, requested scopes, a state value, and the registered redirect URI.
The authorization server authenticates the user and records consent.
It redirects back with a short-lived authorization code.
Claude redeems the code at the token endpoint, supplying the original verifier.
The authorization server returns an access token, and optionally a refresh token when ongoing access is justified.

PKCE binds the authorization code to the client instance that began the flow. If a code is intercepted, it cannot normally be redeemed without the verifier. Use the S256 challenge method, require PKCE at the authorization server, and keep authorization codes short-lived and single-use.

Also validate the redirect URI exactly. Avoid wildcard redirect URIs, string-prefix matching, or accepting a URI supplied by an untrusted request. Preserve and verify state to protect the authorization transaction, and use nonce where your identity layer requires it. These checks are not optional details; they are what keep a browser redirect from becoming an account-linking vulnerability.

Make discovery and registration reliable

A connector should be discoverable instead of depending on a collection of manually copied endpoints. Publish the OAuth authorization-server metadata your deployment requires, plus protected-resource metadata that identifies the resource and the appropriate authorization server. Ensure that the URLs, issuer, token endpoint, supported PKCE method, scopes, and resource identifiers agree across metadata and runtime responses.

Support client registration in the way the connector environment requires. If dynamic client registration is supported, implement it defensively: validate redirect URIs, assign a stable client identifier, and retain only the information needed to enforce policy. If you pre-register clients, document the redirect URI and configuration values precisely. In both cases, treat a client identifier as an identifier—not proof of trust—and avoid relying on a client secret in an environment where it cannot remain confidential.

Test discovery from a clean client session. A hand-crafted token can mask an incorrect issuer, missing resource indicator, or mismatched redirect URI.

Design scopes around tools and data

Scopes should describe meaningful permissions, not broad implementation details. For example, a connector might distinguish projects:read, projects:write, and profile:read. A read-only search tool should not receive the ability to alter projects simply because both tools use the same backend API.

At request time, validate the token’s signature or introspect it according to the token format and issuer. Check at least expiration, issuer, audience or resource binding, and scopes. Then apply application-level authorization: confirm that the authenticated user belongs to the requested tenant and can access the specific record. OAuth scopes alone rarely replace row- or object-level checks.

Define what happens when a model attempts an action without the necessary scope. Return a clear authorization error, not a partial action or an ambiguous tool result. This makes it easier for the client to prompt the user for reconnection or additional consent without exposing data.

Protect token handling and operations

Access tokens should be short-lived. If refresh tokens are issued, protect them as highly sensitive credentials, rotate them where supported, and revoke them when a user disconnects the connector or an account is compromised. Do not return tokens in tool output, store them in plaintext application logs, or include them in error reports.

On the MCP server, use TLS, enforce token validation before the tool handler runs, and limit CORS and callback behavior to the deployment’s needs. Log security events without logging secrets: authorization failures, scope denials, token validation errors, token revocations, and unusual registration activity are useful operational signals.

Test successful authorization, declined consent, expired and revoked access, incorrect audiences, missing scopes, replayed codes, and malformed redirects. mcp-use includes an inspector in local servers and provides a hosted inspector for MCP development workflows.

Frequently Asked Questions

Does a Claude connector need OAuth 2.0? OAuth 2.0 is recommended when the connector accesses user-specific or otherwise protected resources through an interactive authorization experience. A public, read-only connector may not need it, while a service-to-service integration may use a different non-user-delegated credential model.

Why is PKCE necessary if the client has a client ID? A client ID identifies an application; it does not prove that the application initiating the redirect is the legitimate instance. PKCE adds proof tied to the authorization request, helping prevent intercepted authorization codes from being redeemed by another party.

Should each MCP tool have its own OAuth scope? Not necessarily. Create scopes around durable permission boundaries that users can understand, then map each tool to the minimum scopes it needs. Combine scopes only when the underlying operations genuinely carry the same risk and access level.

Can the connector trust a token just because it is signed? No. A valid signature is only one check. The resource server should also verify expiration, issuer, intended audience or resource, and scopes, then enforce tenant and object-level permissions for the requested action.

Conclusion

The safest default for a Claude connector is a remote MCP server that uses OAuth 2.0 Authorization Code flow with PKCE, clear discovery metadata, minimal scopes, and strict token validation at the resource server. Keep user authorization outside the model and outside tool parameters, then enforce access controls for every call. A framework with OAuth support can simplify the server setup, but the essential design remains the same: explicit trust boundaries, least privilege, secure credential handling, and thorough end-to-end testing.

The Best Way to Authenticate Users in a ChatGPT App Built on MCP