MCP Server Authentication for SaaS: API Keys vs OAuth (2026)

If your MCP server runs on your own machine, you probably don't need OAuth; if it is a remote server that your customers connect to from Claude or ChatGPT, you almost certainly do. The choice depends on who connects, where the server runs, and whether the assistant has to act as one specific user. This guide covers what the MCP specification requires, where API keys or personal access tokens are still a sensible choice, and what Claude and ChatGPT say they expect today.

If you want the server built for you, App369 offers a fixed-price MCP Connector for your SaaS. If you are still deciding whether to build one at all, start with how to add an MCP server to your SaaS.

Local vs remote servers

MCP defines two standard transports: stdio and Streamable HTTP. With stdio, the client launches your server as a local subprocess. With Streamable HTTP, the server is a web endpoint that clients reach over the network, which is how a SaaS product normally offers one to many customers. Both are described in the MCP transports specification.

The MCP authorization specification is explicit about the split. Authorization is optional. HTTP-based servers that support it should follow the spec. Servers on stdio "SHOULD NOT" follow it and should instead retrieve credentials from the environment. So a local server that reads MYAPP_API_KEY from an environment variable is normal and spec-aligned. A remote server is a different problem, because the person connecting is a customer you can't hand an environment variable to.

What the spec requires for remote servers

The latest published revision at the time of writing is dated 2026-07-28. The authorization section builds on OAuth 2.1, which is still an IETF draft, not a finished standard. In practice, a remote MCP server that wants to be reachable by standard clients does the following:

• Acts as an OAuth resource server. It accepts bearer tokens in the Authorization header on every request, never in the URL query string.
• Publishes protected resource metadata. The spec says MCP servers MUST implement RFC 9728, and the metadata must name at least one authorization server.
• Answers unauthenticated requests with a 401 whose WWW-Authenticate header points at that metadata. That is how a client discovers where to sign in.
• Has an authorization server with discovery metadata. It must provide either RFC 8414 metadata or OpenID Connect Discovery. This can be your existing identity provider, or one you host with the server.
• Supports a way for the client to get a client ID. The 2026-07-28 revision says authorization servers and clients SHOULD support Client ID Metadata Documents, MAY support Dynamic Client Registration, and marks Dynamic Client Registration as deprecated and kept for backwards compatibility. The earlier 2025-06-18 revision listed Dynamic Client Registration as a SHOULD. If you support both, you are covered either way.
• Uses PKCE on the authorization code flow, and clients send a resource parameter (RFC 8707) that names your server.
• Validates the token's audience. The server must only accept tokens issued for it, and must not pass the token it received on to other APIs. If your MCP server calls your REST API, it should use a credential meant for that API.

That is a lot of moving parts, but most of them are standard features of an identity provider. The part teams underestimate is the first sign-in: the user lands on a consent screen, approves a connection, and your authorization server issues a token tied to that user.

When API keys or personal access tokens are enough

OAuth is the right default for a public, multi-customer remote server. But a key or token is a reasonable choice in some situations:

• Local or internal use. A developer runs your stdio server on their laptop with their own key. This is the case the spec describes for stdio.
• A private connector for one team. An admin connects a custom server for their organization, and everyone shares access to the same data.
• A first version. Your API already issues keys, and you want customers to try the connector before you invest in an OAuth server.

Claude's connector documentation describes a static credential option too: an organization Owner enters an API key or bearer token once, and Claude sends it as a request header on every call. Anthropic marks this as beta and available only to a limited set of organizations. It also says to treat the key as the organization's credential rather than a person's, because every member's requests carry the same key, and to use OAuth if your tools must act as the individual user.

The trade-offs are real:

• Users have to copy secrets. Pasting a key into a settings box is friction, and a pasted key can end up in chat logs, screenshots or notes.
• Scoping is on you. An OAuth token carries scopes the user approved. A key is whatever your key system says it is, so a key that can delete data should not be the same one used for reading reports.
• Rotation is manual. OAuth access tokens are short-lived by design, and the spec recommends short-lived access tokens. Keys tend to live for years unless you build expiry.
• Per-user identity is weaker. If one key serves a whole workspace, your audit log can't say which person asked the assistant to do something.

What Claude and ChatGPT say they expect

Both vendors publish requirements. Check them again before you build, because they change.

Claude. The authentication guide for Claude connectors lists OAuth 2.0 with Dynamic Client Registration and OAuth with Client ID Metadata Documents as supported by default, along with no-auth servers and the beta static-credential option above. It requires a 401 with a resource_metadata pointer, S256 PKCE, and a fixed callback URL for the hosted apps. It says a machine-to-machine client_credentials grant isn't supported, and that Claude gives your discovery and token endpoints 10 seconds to respond.

ChatGPT. OpenAI's Apps SDK authentication documentation says servers that need sign-in should implement an OAuth 2.1 flow that follows the MCP authorization spec, with protected resource metadata, PKCE with S256, and the resource parameter. It names Client ID Metadata Documents as the preferred registration method, with Dynamic Client Registration still supported. It also lets individual tools be declared callable without authentication, and tells servers to verify every token themselves: signature, issuer, audience, expiry and scopes.

The pattern is the same in both: if a user's own account is involved, plan on OAuth.

Practices that hold either way

Whatever you pick, these apply:

1. One credential per user, never one shared key. A shared key can't be revoked for one person and hides who did what.
2. Least-privilege scopes. Start with read access. Put destructive tools behind a separate scope so a user can approve reading without approving deleting. The spec's scope guidance tells clients to request only what they need, and lets your server say which scope a request requires.
3. Don't forward tokens. Your MCP server should authenticate to your API as itself or with a token issued for that API, not with a copy of the one it was handed.
4. Return the right errors. 401 for a missing or invalid token, 403 for insufficient scope.
5. Log every tool call with the user, the tool, a timestamp and the outcome, but never log token values.
6. Make revocation easy. Users should be able to disconnect an assistant from your settings page, and an admin should be able to cut off a user at once. Short-lived access tokens limit how long a leaked one is useful.
7. Keep secrets out of URLs. Both the spec and Claude's documentation say no tokens in query strings.

When to get help

If you have a documented REST API and want an MCP server over it, App369 builds one at a fixed price: the MCP Connector for your SaaS is $2,500 for up to 8 tools over your existing API, with API-key or personal-access-token auth, deployed to your own cloud account, tested in Claude and ChatGPT, with a directory-submission packet. OAuth sign-in is a +$1,000 add-on. Delivery is 10 business days after your API docs and a test key arrive. Directory approval is up to each directory and isn't guaranteed. Simon builds and runs the MCP server for Workspace369, a production Flutter and Firebase SaaS.

Frequently Asked Questions

Does an MCP server need OAuth?

No. The MCP specification says authorization is optional. But if a remote HTTP server wants to work with standard clients that sign users in, the spec's authorization flow is OAuth-based. Local stdio servers are expected to read credentials from the environment instead.

Can I use an API key for a remote MCP server?

Yes, technically. A server can read a key from a request header. Claude documents a beta option where an organization Owner enters a key once, but it treats that key as the organization's credential. For per-user access, use OAuth.

What is protected resource metadata?

It is a JSON document, defined in RFC 9728, that tells a client which authorization server protects your MCP server. The MCP spec requires servers to publish it, and to point to it in the WWW-Authenticate header of a 401 response.

Do I need Dynamic Client Registration?

It depends on the revision. The 2025-06-18 spec recommended it; the 2026-07-28 revision prefers Client ID Metadata Documents and marks Dynamic Client Registration as deprecated, kept for compatibility. Claude supports both, and ChatGPT prefers Client ID Metadata Documents but still supports registration.

How should I revoke access?

Issue per-user tokens, keep access tokens short-lived, and let users and admins disconnect a client from your settings. Revoking one user's grant should not affect anyone else.