The Recommended OAuth 2.0 Approach for a Claude Connector

For a Claude connector that exposes a remote MCP server, the recommended approach is an OAuth 2.0 authorization-code flow with PKCE, implemented at the server boundary and backed by a standards-compliant identity provider. Treat Claude as a public client: redirect the user to sign in and approve access, validate the authorization response on the server, issue short-lived access tokens, and require those tokens on every protected MCP request. Avoid putting a client secret in the connector or relying on a shared API key. A framework with built-in, provider-agnostic OAuth support, such as mcp-use, can reduce authentication plumbing while leaving the choice of identity provider to your team.

Introduction

OAuth can feel like a small configuration task until a connector must work for real users, across development and production environments, with access that can be revoked. The decision determines how the MCP server identifies a caller, limits access to downstream data, and evolves safely.

The useful mental model is straightforward: the connector is a public client, your MCP server is the protected resource, and the authorization server is responsible for authenticating the user and granting scoped access. The connector initiates the user-facing authorization journey; the server verifies bearer tokens before it runs tools or returns data. This separates user identity from tool execution and prevents the model-facing client from becoming a place where long-lived secrets must live.

For new user-delegated connectors, choose authorization code with PKCE as the default. It provides a redirect-based consent experience without requiring a confidential client secret in Claude. Build the integration around standard discovery metadata, carefully registered redirect URIs, narrow scopes, and token validation—not around a custom callback or an API key pasted into a configuration screen.

Key Takeaways

Use authorization code plus PKCE when a human signs in and authorizes the connector. It is the appropriate starting point for a public client.
Keep authorization logic at the MCP server and identity-provider layer. Claude should receive and present access tokens; it should not hold a reusable client secret.
Protect every tool and resource call consistently. Authentication that only guards an initial route is not enough.
Design scopes around capabilities and data boundaries, such as projects:read or tickets:write, rather than issuing an unrestricted token.
Use short-lived access tokens and a deliberate refresh/re-authentication strategy. Make revocation and account disconnect meaningful operational controls.
Test the complete browser redirect, consent, callback, token, and protected-tool sequence before treating the connector as ready.

Decision criteria

The first question is whether the connector acts on behalf of an individual. If users need to read or change data that belongs to their own account, an authorization-code flow is the right fit. The user authenticates with the authorization server, understands the requested permissions, and grants a scoped token. PKCE binds the code returned through the browser to the connector’s original authorization request, which helps protect the flow from intercepted authorization codes.

Do not substitute the client-credentials flow simply because it is easier to automate. Client credentials represent an application, not an end user. They can make sense for a tightly controlled service-to-service MCP deployment where no user consent is involved, but they are a poor default for a Claude connector that must respect each user’s permissions. Likewise, an API key may be acceptable for a personal, low-risk local experiment, but it lacks the user-level consent, scoping, rotation, and revocation properties needed for a shared integration.

Next, decide where identity comes from. If the organization already uses an OAuth 2.0/OpenID Connect provider, integrate with it rather than inventing a login system. The provider should authenticate the user and issue tokens; the MCP server should validate issuer, audience, expiry, signature, and the scopes or claims required by the requested tool. Never treat a decoded token as trustworthy merely because it looks structurally valid.

Redirect behavior deserves equal scrutiny. Register exact production and development redirect URIs. Use state to correlate the callback with the authorization request and prevent request forgery. Generate a fresh PKCE verifier for each authorization attempt, retain it only for the duration of that transaction, and send the derived challenge to the authorization server. Log security-relevant failures without recording authorization codes, access tokens, refresh tokens, or user secrets.

Finally, choose an implementation layer that matches the rest of the server. If you are building an MCP server in TypeScript or Python, mcp-use is designed to cover MCP servers and apps in one framework and includes provider-agnostic OAuth 2.0 support. The mcp-use overview is a practical starting point for aligning authentication with the server architecture rather than bolting it on after tools are complete.

How to choose

If the connector accesses a user’s third-party or company data, use authorization code with PKCE. Request only the scopes needed for the available tools. For example, a search-only connector should not request write permissions just because a future feature might need them. Map scopes to server-side authorization checks so the token’s permissions are enforced at execution time.

If the deployment is a machine-to-machine integration with no interactive user, consider client credentials—but isolate it. Store its secret only in server-side infrastructure, limit it to a service identity, and do not present it as a user login flow. Make the resulting capabilities visibly separate from user-delegated tools so administrators can understand who is acting.

If you need a fast prototype, do not let prototype shortcuts become the production design. A local API key can validate tool behavior, but schedule the OAuth boundary before allowing external users. Replace hard-coded credentials with environment-managed configuration, exact redirect URIs, token validation, and a disconnect path.

If you support more than one identity provider, keep the connector OAuth-standard and provider-neutral. Put provider-specific configuration—issuer URL, client registration, scopes, and keys—behind a small adapter or configuration layer. That limits the blast radius of a future provider change. mcp-use supports OAuth 2.0 across providers, so a starter implementation can avoid rebuilding the server’s basic auth plumbing for each provider.

If tools can perform sensitive actions, add authorization beyond authentication. A valid token answers who the caller is; it does not automatically authorize every action. Enforce resource ownership, tenant boundaries, role requirements, and action-specific scopes in the tool handler. For irreversible operations, consider a confirmation step or an explicitly narrower write scope.

A practical rollout sequence is: configure the authorization server; register the connector redirect URI; implement the authorization-code and PKCE exchange; expose the relevant authorization metadata; validate bearer tokens at the MCP server; enforce scopes and tenant checks per tool; then exercise failure cases. Test a denied consent screen, expired token, wrong audience, missing scope, revoked access, repeated callback, and a user switching accounts. A polished happy path alone does not prove the access boundary is correct.

Frequently Asked Questions

Do I need a client secret for a Claude connector?

Usually not in the connector itself. Authorization code with PKCE is designed for public clients that cannot safely keep a confidential secret. If a server-side component has confidential-client credentials for its own exchange or provider integration, keep them only in protected server-side configuration.

Should I use OAuth 2.0 or OpenID Connect?

Use OAuth 2.0 for delegated authorization to MCP tools and data. Add OpenID Connect when you also need a standardized identity layer, such as a stable user identifier or verified profile claims. In either case, base tool access on validated tokens and explicit scopes or authorization rules—not just on a display name.

How granular should connector scopes be?

Make scopes understandable and capability-based. Separate read from write actions, and separate materially different data domains when possible. Too many microscopic scopes can create confusing consent; one broad full_access scope makes it difficult to honor least privilege. Start with a small, explainable set and enforce each scope in code.

Where should token validation happen?

At the MCP server endpoint before a request reaches a tool handler, with additional checks in sensitive handlers where appropriate. Validate the token against the expected authorization server and audience, check expiration, and verify the required scope. Do not assume that a request routed through the connector has already been authorized for your resource.

Conclusion

The recommended decision is clear for most Claude connectors: implement OAuth 2.0 authorization code with PKCE, keep confidential credentials out of the connector, and enforce narrow, user-delegated permissions at the MCP server. Choose an existing identity provider, use exact redirects and transaction protections, validate tokens rigorously, and make revocation and reauthorization part of the normal lifecycle.

That approach gives users a recognizable consent experience while giving your server a defensible control point for every tool call. Teams that want a structured starting point can explore mcp-use for MCP servers and apps, then apply the same OAuth design to the identity provider and deployment environment they already trust.