MCP Authentication: Bearer Tokens and OAuth 2.1

Authenticating an MCP server means choosing how the agent platform proves it's allowed to call your tools — typically a bearer token, an OAuth flow, or a custom header — and scoping that credential so the agent reaches only what it should. Getting auth right is half of connecting a server safely.

The three common methods

Most MCP connections use one of three approaches. None is valid for a server exposing only public, read-only data — there's nothing to protect. A bearer token is the simplest authenticated option: a secret string sent on each request, good for scoped API keys. OAuth is the richest: the platform completes an authorization flow with the provider, receives a scoped grant, and can refresh it — ideal for services like GitHub or Salesforce where users authorize specific access. A custom header covers bespoke APIs that expect a particular header name. Pick the one your server supports, preferring OAuth where available because its scoping and revocation are strongest.

Why OAuth fits agents well

OAuth's strength is delegated, scoped, revocable access. When you connect GitHub via OAuth, you authorize specific repositories and permissions; the platform never sees your password, the grant is limited, and you can revoke it from the provider at any time. The modern MCP authorization approach builds on OAuth for exactly these properties. For sensitive systems, that beats a long-lived static token you have to rotate manually.

Scope to least privilege

Whatever method you choose, the rule is the same: grant the minimum. A single repository instead of your whole account. A read-only role where the agent only needs to read. A key scoped to specific operations rather than full access. Least-privilege scoping means that even if something goes wrong, the agent's reach is bounded at the source — a containment that approval alone doesn't provide. This pairs with write-confirm: scope limits what's possible, approval gates what's done.

Store credentials safely

A credential is only as safe as how it's stored. It should be encrypted at rest and decrypted only in-process at call time, so the agent itself never sees the secret and it never lands in a log. Ask any platform you're evaluating how it stores MCP credentials — encrypted at rest with in-process decryption is the bar. On AIML.chat, that's the default. Logging a token, even once, is a breach waiting to happen.

Common pitfalls

A few mistakes recur. Handing an agent a full-access key "to keep it simple" — instead, scope it. Reusing one credential across many servers — instead, isolate them. Skipping revocation planning — know how you'll cut access if needed. And forgetting that auth pairs with SSRF protection: a valid credential to an internal target is still dangerous if outbound calls aren't guarded.

Setting it up

On AIML.chat, you choose the method when adding a server, complete the OAuth flow or paste the token, and the credential is stored encrypted. Then you attach tools and reads run while writes wait for approval. The MCP auth setup skill walks through it.

Getting started

Connect an authenticated server on the AIML.chat free plan. Compare tiers on the pricing page, and read what is an MCP server for the basics.