This comparison is part of our MCP comparisons, within The MCP Guide. Facts are checked against each vendor's own documentation and pricing pages on the date shown.
Use OAuth for remote MCP servers that people connect to from AI apps, because it gives each user their own scoped, revocable access. Use an API key for local stdio servers and for unattended agents that cannot complete an OAuth sign-in, and keep that key narrowly scoped. The MCP specification itself draws the line by transport.
Checked against: the MCP authorization spec, its security considerations page and the security best practices of the 2026-07-28 specification, read on 28 October 2026, plus vendor docs cited below.
OAuth is a standard for granting an app limited access to an account without sharing a password. The user signs in and approves, and the app gets a short-lived token. An API key is a long-lived secret string that the app sends with each request. Both can protect an MCP server. They differ in who holds the secret, how long it lasts and how easy it is to limit and revoke.
Key Takeaways
- The spec says authorization is optional, but HTTP-based servers "SHOULD conform" to its OAuth-based flow.
- For stdio servers, the spec says they "SHOULD NOT follow this specification, and instead retrieve credentials from the environment," which usually means an API key.
- OAuth tokens in MCP must be bound to the specific server (audience) and should be short-lived; refresh tokens must rotate for public clients.
- API keys are simpler and work for unattended agents, but they last until someone revokes them and are often broader than needed.
- Major vendors now offer both: Stripe and GitHub accept OAuth or a key on their MCP servers.
At a glance
| OAuth (MCP authorization spec) | API keys | |
|---|---|---|
| Spec status | The defined flow for HTTP transports | Not defined by the spec; the stdio rule points to environment credentials |
| Typical transport | Streamable HTTP (remote) | stdio (local), or HTTP via a bearer header |
| Who signs in | Each user, in a browser consent screen | Nobody; the key is pasted into config |
| Lifetime | Short-lived access tokens, rotated refresh tokens | Until revoked or expired by the owner |
| Scope control | Scopes requested and granted per user, step-up possible | Whatever the key was created with |
| Bound to one server | Yes, audience validation is required | Depends on the vendor |
| Revocation | Per user or per client session | Per key |
| Setup effort | Authorization server, metadata, client registration | Low |
| Best for | Interactive AI apps, many users | Local tools, CI jobs, autonomous agents |
What the spec requires
The authorization spec opens with: "Authorization is OPTIONAL for MCP implementations." When supported:
- HTTP-based implementations "SHOULD conform to this specification."
- stdio implementations "SHOULD NOT follow this specification, and instead retrieve credentials from the environment."
- Other transports "MUST follow established security best practices for their protocol."
The spec's flow is built on OAuth 2.1 and related standards, including Protected Resource Metadata (RFC 9728), Resource Indicators (RFC 8707) and Client ID Metadata Documents. The MCP server acts as an OAuth resource server, and a separate authorization server issues tokens. Our MCP authorization spec guide walks through each step.
Token rules matter most. Servers "MUST validate that access tokens were issued specifically for them as the intended audience." Invalid or expired tokens "MUST receive a HTTP 401 response." And clients "MUST NOT send tokens to the MCP server other than ones issued by the MCP server's authorization server."
Where OAuth is stronger
Per-user access. Each person signs in and grants access, so the server knows who is acting. Audit logs then show real users, not one shared key.
Short lifetimes. The security considerations page says authorization servers "SHOULD issue short-lived access tokens to reduce the impact of leaked tokens." For public clients, they "MUST rotate refresh tokens."
Least privilege by design. The best practices page recommends a "progressive, least-privilege scope model": start with a minimal scope and ask for more through a WWW-Authenticate challenge only when a privileged tool is first used. API keys rarely support this kind of step-up.
Easy revocation. Stripe's MCP docs say "OAuth lets you authorize and revoke a client without sharing an API key." Users and admins can revoke OAuth sessions from the Dashboard.
Works in hosted AI apps. For Stripe's connector in Claude and its plugin in ChatGPT, the docs describe signing in and granting permissions "using the OAuth window when prompted." No key is pasted anywhere.
Where API keys are stronger
Local servers. For stdio, the spec itself points to environment credentials. GitHub's MCP server README lets the local server read a GITHUB_PERSONAL_ACCESS_TOKEN, which "takes precedence over OAuth."
Unattended agents. Some agents run with no human to click a consent screen. Stripe says: "For autonomous clients that can't use OAuth, create an agent API key with only the permissions the client needs."
Client compatibility. Not every MCP client supports OAuth. Stripe's docs say: "Use OAuth when your client supports it. If your client doesn't support OAuth, use an agent API key as a bearer token." GitHub says any host that supports remote servers "should support the remote GitHub server with PAT authentication."
Simplicity. There is no authorization server, metadata endpoint or client registration to run. For an internal tool with one user, that can be the right trade.
Pricing
Neither method has a protocol fee. OAuth costs more to run. You need an authorization server, either self-hosted or from a vendor. Many vendors offer free tiers, as our WorkOS vs Auth0 comparison shows. API keys cost little to issue, but the hidden cost is managing, rotating and auditing secrets across machines.
Security and admin controls
OAuth pitfalls. The biggest mistake is accepting tokens meant for another service, or forwarding a client's token to a downstream API. The best practices page calls this "token passthrough" and says it "is explicitly forbidden in the authorization specification." See MCP token passthrough and MCP OAuth misconfiguration.
API key pitfalls. Keys leak through config files, logs and repos. GitHub's README advises to "only grant necessary permissions," use separate tokens per project and keep tokens out of version control.
Vendors are tightening keys. Stripe's MCP docs say that starting in December 2026, "Stripe MCP will stop accepting full-access secret keys and restricted API keys without the Agent tag." It asks users to migrate by 30 November 2026 to agent API keys or OAuth. Expect more vendors to require narrow, labeled keys for agents.
For admins. Stripe lets administrators enable or disable MCP access for the whole team and revoke other users' OAuth sessions. Look for similar controls in any server you approve.
Which to choose
Pick OAuth if:
- You run a remote MCP server for customers or many staff.
- You want per-user permissions, audit trails and one-click revocation.
- You plan to list your server in AI app directories.
Pick API keys if:
- The server runs locally over stdio.
- An unattended agent or CI job must call the server with no human present.
- The client you must support has no OAuth support.
Offer both if you are a SaaS vendor. Stripe and GitHub both accept OAuth and keys on their remote servers. Default to OAuth, and make keys narrow, labeled and easy to rotate.
Next step
Decide your auth model before you build tools, because scopes shape tool design. eSEOspace sets up OAuth and key handling in our MCP development projects and reviews existing servers in the MCP readiness audit. See all MCP comparisons.
Frequently asked questions
Does the MCP spec require OAuth?
No. The 2026-07-28 spec says authorization is optional. When an HTTP server does support it, the spec says it should conform to the OAuth-based flow. For stdio, it says to read credentials from the environment instead.
Can I put an API key in the URL of a remote MCP server?
The spec does not define that pattern. Vendors that accept keys, such as Stripe, ask for them as a bearer token in the Authorization header. Keys in URLs tend to end up in logs and browser history, so avoid them.
Is a personal access token the same as an API key?
For this comparison, yes. A personal access token, like GitHub's, is a long-lived secret tied to a user account. It behaves like an API key: easy to use, but it lasts until revoked and carries whatever permissions you gave it.
What about Dynamic Client Registration?
That is part of OAuth, not an alternative to it. The 2026-07-28 spec deprecated Dynamic Client Registration in favor of Client ID Metadata Documents for registering clients with an authorization server.
