OAuth for MCP servers, explained for business owners

The question OAuth answers

When Claude or ChatGPT calls a tool on your MCP server, the server has to know two things: who is asking, and what they are allowed to reach. OAuth is the standard way to answer both without anyone handing over a password. The person signs in to your system once, approves the connection, and the assistant receives a token that represents that person and nothing more.

Anthropic's support article describes it from the user's side: adding a custom connector typically involves an OAuth sign-in that lets Claude act on your behalf without ever seeing your password, and you can revoke it at any time.

Why a shared API key is risky

Shared keys tend to appear for understandable reasons: the source system's API only issues one key, or the first prototype needed to work quickly. If a source system truly cannot issue per-user credentials, the server can still sign people in with OAuth through your identity provider, then apply each person's permissions itself before using the system key. That keeps the key out of the assistant and makes the server, not the key, decide who sees what.

The shortcut is one API key, stored in the connector, used for every request. It works on day one. The problem is who it works for. Anthropic states plainly that on Team and Enterprise plans, everyone who uses a connector with a fixed credential reaches the service with that same credential.

• Everyone sees everything the key can see. A sales assistant and the CFO get the same access.
• Your source system's own permissions stop mattering, because it only sees one user.
• Logs show the key, not the person, so you cannot tell who asked for what.
• Removing one person's access means rotating the key for everyone.
• If the key leaks, it works for anyone who holds it until you notice.

What per-user OAuth gives you

With per-user OAuth, Anthropic notes that Claude inherits each person's permissions from the connected service: if someone cannot open a file or record in the source system, the connector cannot reach it from Claude either. OpenAI's plugins page makes the same point for ChatGPT, saying it only accesses information the user can already see in the connected plugin.

That means your existing permission model, the one your IT team already manages, keeps working. Leavers lose access when their account is disabled. Audit logs name real people.

What the MCP specification requires

You do not need to read the specification yourself. You need a builder who can show you that each of these is in place, ideally with a test that proves a token for another service is refused.

The MCP authorization specification is based on OAuth 2.1 and applies to remote servers that use HTTP. A few of its rules matter to buyers because they are where weak builds cut corners:

• Audience checks: servers must validate that each access token was issued specifically for them, so a token meant for another service is rejected.
• No token passthrough: the security guidance explicitly forbids a server accepting a client's token and passing it straight to a downstream API.
• PKCE: clients must use it, which protects the sign-in code from being intercepted.
• Discovery: the server publishes metadata that tells the assistant where to sign in. OpenAI's guide describes this as a protected resource metadata endpoint on your server.

OAuth is not the whole answer

A token tells the server who is calling. The server still has to check, on every call, whether that person may reach the specific record requested. Tenant, account, and access group should come from the verified token, never from anything the model sends. OpenAI's docs say annotations and client confirmations do not replace authorization in your server.

Local servers are different. The specification says servers using the stdio transport should not follow the OAuth flow and should take credentials from the environment instead, which is one reason local servers suit single-user developer setups rather than company rollouts.

How sign-in looks for your team

For the people using the connector, OAuth is a familiar step. In Claude, an owner adds the connector once, then each member opens Connectors and clicks Connect, which opens the sign-in page of your system or identity provider. After approving, they are returned to Claude and the connector is ready.

In ChatGPT, OpenAI's guide describes the same pattern. ChatGPT reads your server's metadata to find the sign-in page, the user signs in, and ChatGPT holds a token for that user. OpenAI also notes that ChatGPT Enterprise workspaces can verify email domains, and the guide describes how an authorization server can restrict sign-in to the organization's own workspace.

When someone leaves, disabling their account in your identity provider stops new tokens. Users can also disconnect the connector themselves, and Anthropic notes permissions can be revoked in Claude's settings or in the third-party service.

What to ask your builder

Ask whether the server uses per-user OAuth or a shared key, which identity provider it uses, whether it validates token audience, and where permission checks happen. Prestyj's custom Claude connectors and custom MCP servers use per-user OAuth with server-side checks by default, connected to the identity provider you already run.