MCP Security · Identity
MCP Authentication Patterns
Four ways to establish who is calling an MCP server. Most deployments use the weakest one, because it is the one that appears in the quickstart.
The short answer
MCP does not mandate an authentication mechanism, so four patterns have emerged: static API keys, delegated OAuth, workload identity, and token exchange at a gateway. They differ in what they actually prove. A static key proves someone holds the key; the other three can prove which agent, on whose behalf, for how long. Choose by what you need to be able to revoke, and by whether a human is present.
What authentication has to answer
For a human logging into an application, authentication answers one question: which person is this? For an agent calling a tool, three questions matter, and most implementations only answer the first.
Three questions, not one
Which workload is calling? Not “a valid client” — which specific agent, distinguishable from the others, revocable on its own.
On whose behalf? Whether the action carries a specific person’s authority, or the agent’s own. These are different privileges and should not be conflated.
For how long? A credential with no expiry is a permanent grant. Sessions end; secrets in config files do not.
Worth stating plainly, because the two get merged constantly: authentication establishes who is calling. Authorization decides whether that caller may invoke this tool with these values. Many MCP deployments implement the first and skip the second, which is why a valid credential so often unlocks the entire tool surface.
The four patterns
Static API key in client configuration
A long-lived secret pasted into the MCP client config. Universal in quickstarts because it works in thirty seconds, and it is the source of most credential findings in real deployments.
It identifies the key, not the caller. It is typically shared across agents and machines, sits in plaintext on developer laptops, rarely rotates, and cannot be revoked for one agent without breaking everyone else using it. Per-agent audit is impossible by construction.
Acceptable when: local development against non-production data. Nowhere else.
Delegated OAuth — acting for a user
The user consents, the server receives a scoped access token, and the agent acts with that person’s authority and no more. The permission model you already maintain in the target system does the work, which is its real advantage.
The constraint is a user has to be present to consent, and tokens expire. Refresh handling becomes real infrastructure, and a background agent running at 3am has nobody to ask.
Right when: the action should carry a specific human’s authority — interactive assistants touching that person’s own data.
Workload identity — the agent as a first-class principal
The platform issues the agent process a short-lived, cryptographically verifiable credential — the same mechanism modern services use to authenticate to each other. No secret is stored anywhere; the runtime attests to the identity and it rotates automatically.
Each agent becomes independently revocable and independently auditable. The cost is that it requires platform support, and it says nothing about which user a request came from.
Right when: unattended agents doing work that belongs to the system, not to a person — pipelines, monitors, scheduled operations.
Token exchange at a gateway
The agent authenticates once to a gateway, which evaluates policy and mints a narrowly scoped, short-lived token for the specific downstream server and call. Servers never see the agent’s original credential and never hold long-lived secrets for their targets.
Both the workload identity and the acting user can be carried through, so authorization decisions have full context and the audit record has a real subject. It requires running a gateway — which most deployments end up needing anyway.
Right when: more than a couple of servers, more than one privilege level, or any server you did not write.
Side by side
| Static key | Delegated OAuth | Workload identity | Gateway exchange | |
|---|---|---|---|---|
| Identifies | The key | The user | The agent | Both, per call |
| Lifetime | Indefinite | Token lifetime | Minutes, auto-rotated | Per call |
| Revoke one agent | Not possible | Per user, not per agent | Yes | Yes, instantly |
| Secret at rest | Plaintext config | Refresh token | None | None downstream |
| Per-agent audit | No | Partial | Yes | Yes, with policy decision |
| Works unattended | Yes | Poorly | Yes | Yes |
| Setup cost | Minutes | Days per integration | Platform-dependent | One gateway, then trivial |
Scroll the table horizontally on narrow screens.
The confused deputy problem
The most common authentication failure in MCP is not a weak secret. It is authority substitution — the confused deputy problem in a new setting: the server authenticates the caller correctly, then executes against the target using its own service account.
A read-only analyst asks a question. The agent calls the server. The server, holding an admin credential because that was simplest, performs the operation successfully. The analyst just exercised admin privilege, and every log in the target system attributes it to the service account.
The rule
Authority must survive the hop. Either propagate the caller’s identity to the target system, or have the enforcement point apply the caller’s permissions before the call is made. What you cannot do is authenticate carefully at the front door and then act as somebody more powerful on the other side of it.
Choosing, in practice
Three questions settle it. Answer them in order and stop at the first that applies.
- 01Does the action need a specific person’s authority?If yes, delegated OAuth — the agent then cannot exceed what that user could do alone, and the target system’s existing permission model carries the weight.
- 02Is there more than one server, or one you didn’t write?If yes, gateway token exchange. Implementing identity separately per server means the weakest implementation sets your posture.
- 03Single internal server, unattended, platform available?Workload identity is proportionate and stores no secret. Revisit when the second server appears — which it will.
Static keys are not on the list. If you have them in production, the fastest improvement is not a migration project — it is putting a gateway in front and letting it hold the downstream credential, so the key stops living on developer machines. That path is in MCP gateway vs MCP server.
The product
One identity model, applied at every call
Barzel Central Gateway authenticates each agent once and mints scoped, short-lived credentials per downstream call — so servers hold no long-lived secrets and revoking an agent takes one change.
Frequently asked questions
What is wrong with static API keys for MCP?
A static key identifies the key, not the caller. It rarely rotates, is usually shared, sits in plaintext config on developer machines, and cannot be revoked for one agent without breaking every other holder. Per-agent audit becomes impossible.
Should MCP servers use OAuth?
When the action should carry a specific human’s authority, yes — it is the cleanest way to keep the agent inside that user’s existing permissions. For unattended background agents it fits badly, since no user is present to consent.
What’s the difference between authentication and authorization here?
Authentication establishes who is calling; authorization decides whether that caller may invoke this tool with these values. Deployments commonly do the first and skip the second, which is why a valid credential often grants the whole tool surface.
Can one agent hold several identities?
It generally should. Its own workload identity establishes which agent is running; a delegated user token establishes on whose behalf a particular action is taken. Collapsing the two into one credential is how privilege quietly widens.
Is mutual TLS sufficient on its own?
It authenticates the connection well and says nothing about the call. You still need per-agent identity inside the session, tool-level authorization and parameter bounds — a trusted channel is not an authorised action.
Sources and further reading
Primary specifications and standards this article relies on. Where a claim is our own judgement rather than something a standard states, the article says so in the text.
- 01 · IETF RFC 6749 — The OAuth 2.0 Authorization Framework ↗ Normative definition of delegated authorization.
- 02 · IETF RFC 8693 — OAuth 2.0 Token Exchange ↗ The standard mechanism behind the gateway token-exchange pattern.
- 03 · IETF OAuth Working Group OAuth 2.0 Security Best Current Practice ↗ Current guidance on token handling, rotation and common failure modes.
- 04 · CNCF SPIFFE — Secure Production Identity Framework ↗ Reference model for short-lived, attested workload identity.
- 05 · Reference definition The confused deputy problem ↗ Origin of the authority-substitution failure described above.
- 06 · MCP project Model Context Protocol — specification ↗ The normative spec, including capability negotiation and authorization.
Last reviewed 18 August 2026. External links open in a new tab; we do not control their content.
Try it against a real server
If you want to exercise a client’s transport and handshake without any credential in the way, there is a free server for exactly that. Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run — no signup, no key, 54 tools. A tools/list call takes about a minute and confirms your client works before you point it at anything that governs production. Setup is in the reference.
Reference documentation
Want the specification rather than the argument?
The credential model for each of the five servers, side by side, and what a scope challenge looks like.
Free tier · 1,000 calls/mo · on the MCPize marketplace
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.