Identity · tokens
MCP OAuth Security: Tokens, Scopes and Delegation
Most MCP token handling validates the signature and stops. A valid signature proves the token is genuine. It does not prove it was issued for your server, for this caller, or for anything you should honour.
The short answer
MCP OAuth security requires seven validation checks on every request, not one: signature, issuer, audience, expiry, not-before, scope and subject type. Audience binding is the check most often omitted and the one that prevents a token issued for another service being replayed against your MCP server. Tokens must be validated per request rather than at connection, and never accepted through a tool parameter. Seven checks, three delegation patterns, four leakage paths, and an eight-point hardening list.
Key takeaways
- 01Validate on every request, not at connection. A long-lived session with connection-time validation keeps a revoked agent working for hours.
- 02Audience binding is the check that stops token replay across services. It is also the one most implementations skip.
- 03A bearer token in a tool parameter is a credential in your logs, your model’s context and your telemetry store. Never accept one there.
- 04Scopes should name capabilities, not systems.
refund:issueis enforceable;payments:adminis a blank cheque. - 05Token exchange (RFC 8693) is how caller authority survives the gateway hop without collapsing into a service account.
- 06Short lifetimes beat revocation lists. A five-minute token makes revocation a timing problem rather than a distributed-state problem.
Seven checks, every request
The common implementation decodes the JWT, verifies the signature against the issuer’s public key, and proceeds. That is one check out of seven, and it establishes only that somebody with the issuer’s key signed something — not that it was meant for you.
Key facts
- ▸A valid signature proves authenticity, not applicability. Audience proves applicability.
- ▸Validate per request. Connection-time-only validation means revocation does not take effect until the session ends.
- ▸Clock skew tolerance should be seconds, not minutes — a generous window on
expis a revocation delay.
| Check | Claim | Failure mode if skipped |
|---|---|---|
| Signature | — | Forged tokens accepted. The one everyone does |
| Issuer | iss | Tokens from any issuer with a valid-looking key accepted |
| Audience | aud | A token issued for another service replays against yours |
| Expiry | exp | Tokens work forever; revocation becomes meaningless |
| Not before | nbf | Pre-issued tokens usable ahead of their validity window |
| Scope | scope / scp | Authenticated callers can invoke anything they can reach |
| Subject type | sub + custom | Agent tokens and human tokens treated identically, so attribution collapses |
Two implementation notes that matter more than they look. Cache the issuer’s signing keys with a bounded TTL and handle rotation, or a key roll becomes an outage. And on validation failure, return a generic error to the caller while logging the specific reason internally — telling an attacker which of the seven checks failed is free reconnaissance.
Why audience binding is the one that matters
Consider an estate where the identity provider issues tokens to an agent for several services: a CRM API, an internal analytics service, and your MCP server. All signed by the same issuer, all with valid signatures, all unexpired.
Without audience validation, a token issued for the analytics service — which might be low-sensitivity, broadly distributed and logged in more places — is accepted by your MCP server as proof of identity. An attacker who obtains the weakest token in your estate can use it against the strongest service.
This is not theoretical; it is the standard token-replay path and it is why aud exists. The fix is one comparison: reject unless the audience claim names your MCP server specifically. Not your organisation, not a shared API identifier — your server.
There is a related trap in the MCP setting. A gateway sitting in front of several servers may be tempted to accept one audience for all of them. That collapses the boundary the audience claim was drawing: a token good for the low-risk documentation server becomes good for the payments server. Issue per-server audiences, or per-capability-group audiences at minimum.
Key facts
- ▸An attacker uses the weakest token in the estate against the strongest service. Audience binding closes that path.
- ▸One shared audience across all MCP servers recreates the problem the claim exists to solve.
- ▸Audience validation is a string comparison. There is no performance argument for skipping it.
Scope design
Scopes are the coarse filter that runs before policy evaluation, and their granularity determines whether that filter means anything. Three rules.
Name capabilities, not systems
refund:issue is enforceable and reviewable. payments:admin is a blank cheque whose meaning drifts as the payments service gains features. Scope names should read like the actions they permit.
Separate read from write, always
ledger:read and ledger:write as distinct scopes, never a combined ledger. Most agents need only the first, and a read-only token limits an entire class of incident.
This is the highest-yield scope decision available and it costs nothing at design time. Retrofitting it means re-issuing every token.
Scopes are necessary, not sufficient
A scope grants a class of operation. It cannot express that a refund of £80 is routine and £80,000 is not, because scopes are issued before any amount exists. Parameter-level policy does that — see runtime authorization.
The failure is treating scope as the whole authorization story. Scope answers “may this class of thing happen?”; policy answers “may this thing happen now?”
Three delegation patterns
When an agent acts for a human, something has to carry that fact to the backing system. Three patterns, and only one of them preserves accountability.
| Pattern | What the backing system sees | Attribution | Verdict |
|---|---|---|---|
| Shared service account | One identity for all callers | None — every action attributed to the service | Avoid. Makes audit, revocation and rate limiting per-caller impossible |
| Token pass-through | The original caller’s token, forwarded unchanged | Full, but the token’s audience is now wrong and its scope is unreduced | Weak. Violates audience binding and cannot narrow privilege |
| Token exchange (RFC 8693) | A new token naming the original subject, scoped down, audience-bound to the target | Full, with reduced privilege | Correct. The only pattern that satisfies both attribution and least privilege |
Token exchange is the mechanism that solves the confused-deputy problem at a gateway. The gateway presents its own credentials plus the inbound token, and receives a downstream token that says: this action is being taken on behalf of this human, by this agent, limited to this scope, valid for this target, for the next five minutes. Every property you need is in the token rather than in an assumption.
The practical objection is that not every backing system supports it. Where it is unavailable, the fallback is a per-user credential rather than a pooled one — and where even that is impossible, record the delegation explicitly in your own evidence record so attribution survives even though the backing system cannot see it.
Four leakage paths specific to agents
Bearer tokens leak in ordinary web systems too. Agent estates add paths that conventional threat models do not cover, because a language model is in the loop and it treats text as text.
Tokens in tool parameters
A tool that accepts an auth_token parameter puts a credential into the model’s context, the request payload, your telemetry and possibly the evidence record. The model may then repeat it in a response.
Never accept credentials through tool parameters. Authentication belongs in the transport layer. If a third-party server requires this, treat it as a design defect and isolate the server hard — its credential should be narrow and its egress restricted.
Tokens echoed in tool responses
A server returning its own request context, or an error message containing the received token, feeds that token straight into the model’s context where it may be summarised, logged or repeated.
Scan tool responses for credential-shaped strings at the enforcement point and redact before the response reaches the model. Cheap, and it catches an entire class of accident.
Tokens in the diagnostic tier
Full-payload telemetry captures headers. The observability store typically has broader read access than the systems the credentials reach.
Redact at write time, not read time, and hash payloads rather than storing them — the two-tier design exists partly for this.
Long-lived tokens in client configuration
A static key in a developer’s MCP client config file is a credential on a laptop, in a repository, and in every backup of both. It also cannot be revoked without breaking whoever else copied it.
Short-lived tokens obtained through a proper flow. If a static key is genuinely unavoidable, scope it to read-only and rotate it on a schedule you actually keep.
Built on this thinking
Per-user OAuth, validated per request, at one point
Barzel Central Gateway terminates agent connections with per-user OAuth/OIDC, validates every request rather than every session, and preserves caller authority across the hop instead of collapsing it into a service account — so attribution survives to the backing system and to the audit record.
Eight-point hardening checklist
Each with the failure it prevents. Roughly a week of engineering for a server you own.
| Control | Prevents | Effort |
|---|---|---|
| All seven validation checks, per request | Replay, forged issuer, expired-token acceptance | 1–2 days |
| Per-server audience values | One token spanning services of different sensitivity | Hours, plus IdP config |
| Token lifetime under 15 minutes | Revocation lag; stolen-token usefulness | Hours |
| Read and write as separate scopes | A read-only agent being able to mutate state | 1 day, more if retrofitting |
| Token exchange for delegation | Confused deputy; unattributable actions | 2–3 days |
| Credentials rejected in tool parameters | Tokens entering model context and telemetry | Hours — a schema check at the gateway |
| Response scanning for credential-shaped strings | Tokens echoed back into context | 1 day |
| PKCE on every authorization code flow | Code interception on public clients | Hours; default in OAuth 2.1 |
Two additions worth considering once the eight are done. Sender-constrained tokens (mTLS or DPoP) remove the bearer property entirely, so a stolen token is useless without the client’s key — the right answer for X-class capabilities. And step-up authentication for high-consequence actions, where the human re-authenticates rather than the agent being blocked outright.
What OAuth does not solve
OAuth establishes who is calling and what class of operation they may perform. It says nothing about whether this specific call, with these values, should proceed. A perfectly validated token with correct audience and minimal scope will happily authorise a £2m transfer if the scope permits transfers, because scopes are issued before amounts exist.
It also does not address the reason an agent decided to act. A token proves the caller is who it claims; it cannot indicate that the caller was persuaded by an instruction hidden in a document. Identity and intent are separate problems, and only the first is an OAuth problem — see MCP prompt injection for the second.
And OAuth’s guarantees degrade to the weakest participant. One MCP server accepting a static shared key sets the real posture for anything reachable through it, however rigorous the rest of the estate is. The audit question worth asking quarterly is not whether you use OAuth but whether anything still accepts something else.
Frequently asked questions
What checks should an MCP server perform on an OAuth token?
Seven, on every request: signature, issuer, audience, expiry, not-before, scope and subject type. Validating only the signature proves the token is genuine but not that it was issued for your service.
What is audience binding and why does it matter for MCP?
Validating that the token’s aud claim names your specific MCP server. Without it, a token issued for any other service by the same issuer is accepted — so an attacker can use the weakest token in your estate against the strongest service. It is a string comparison with no performance cost.
Should MCP tokens be validated per request or per connection?
Per request. Connection-time-only validation means a revoked agent keeps working until its session ends, which on a long-lived connection can be hours.
How long should an MCP access token live?
Under fifteen minutes. Short lifetimes turn revocation into a timing problem rather than a distributed-state problem, and they sharply limit the usefulness of a stolen token.
How should MCP scopes be designed?
Name capabilities rather than systems — refund:issue rather than payments:admin — and always separate read from write as distinct scopes. Scopes are a necessary coarse filter but not sufficient: they are issued before any parameter value exists, so they cannot distinguish a £80 refund from an £80,000 one.
What is the correct way to delegate authority to an MCP agent?
Token exchange under RFC 8693: the gateway swaps the inbound token for a downstream one that names the original human subject, is scoped down, and is audience-bound to the target. Shared service accounts destroy attribution, and token pass-through violates audience binding while failing to narrow privilege.
Can an MCP tool accept a token as a parameter?
No. A credential in a tool parameter enters the model’s context, the request payload, your telemetry and possibly the audit record, and the model may repeat it in a response. Authentication belongs in the transport layer; reject credential-shaped parameters at the gateway.
How do tokens leak in AI agent estates specifically?
Four paths: credentials passed as tool parameters, tokens echoed back in tool responses into model context, full-payload telemetry capturing headers into a store with broader read access, and long-lived static keys sitting in developer client configuration files and every backup of them.
What are sender-constrained tokens and when are they worth it?
Tokens cryptographically bound to the client that requested them, using mTLS or DPoP, so possession alone is insufficient and a stolen token is useless. Worth the complexity for irreversible-action capabilities, where bearer semantics are the residual risk.
Does OAuth secure an MCP deployment on its own?
No. It establishes identity and operation class, not whether a specific call with specific values should proceed, and it cannot tell you the agent was persuaded by injected content. Its guarantees also degrade to the weakest participant — one server accepting a static shared key sets the posture for everything reachable through it.
Glossary
- Audience binding
- Validating that a token’s <code>aud</code> claim names your service, so a token issued for a different service cannot be replayed against yours.
- Token exchange
- RFC 8693: swapping an inbound token for a narrower downstream token that preserves the original caller’s identity while reducing its scope.
- Confused deputy
- A component acting with its own elevated authority on behalf of a less privileged caller, so the caller effectively gains privilege it was never granted.
- Bearer token
- A credential whose possession alone authorises use, meaning anyone who obtains it can act as the holder until it expires.
- Sender-constrained token
- A token cryptographically bound to the client that requested it, so possession alone is insufficient — the mitigation for bearer-token theft.
Sources and further reading
Token semantics, validation requirements and delegation mechanics are specified in the IETF documents cited below, which are authoritative. The MCP-specific leakage paths and the hardening checklist are our own.
- 01 · IETFRFC 6749 — The OAuth 2.0 Authorization Framework ↗The base grant model that MCP authorization builds on.
- 02 · IETFOAuth 2.1 — draft specification ↗Consolidated current best practice for authorization, including PKCE by default.
- 03 · IETFRFC 9068 — JWT Profile for OAuth 2.0 Access Tokens ↗Claim structure a gateway can validate without calling back to the issuer.
- 04 · IETFRFC 8693 — OAuth 2.0 Token Exchange ↗The mechanism for preserving caller authority across a gateway hop.
- 05 · IETFRFC 7519 — JSON Web Token ↗Claim set, signature and validation rules every token check has to implement.
- 06 · IETFRFC 7636 — Proof Key for Code Exchange ↗PKCE, now default in OAuth 2.1 and required for public clients.
- 07 · IETFRFC 9700 — Best Current Practice for OAuth 2.0 Security ↗Current consensus on token handling, redirect validation and mix-up defences.
- 08 · MCP projectModel Context Protocol — specification ↗Normative source for tool schemas, capability negotiation and the authorization model.
- 09 · NISTNIST SP 800-63 — Digital Identity Guidelines ↗Assurance levels behind step-up authentication and re-authentication decisions.
Last reviewed 2 September 2026. External links open in a new tab; we do not control their content.
Cite this article
Alex, M. (2026). MCP OAuth Security: Tokens, Scopes and Delegation. Real Biz Digital. https://realbizdigital.net/insights/mcp-oauth-security/
Try the mechanics on a live server
To watch a real tools/list response before you point a client at anything that governs production — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
Barzel Central Gateway is this layer, sold as a running product
Twenty-five tools covering identity-aware policy, tool routing, risk scoring, approvals, routebooks, workflow simulation and SIEM evidence. Ten policy inputs, six enforcement outcomes, per-user OAuth/OIDC. The Community tier is free, so an evaluation costs an afternoon rather than a purchase order.
| Plan | Price | Included | Right for |
|---|---|---|---|
| Community | Free | 1,000 tool calls/mo · full policy engine, registry, audit | Evaluating the estate, or a single team proving the path works |
| Starter | $10/mo | 10,000 calls/mo | One or two production agents against a handful of servers |
| Team | $79/mo | 100,000 calls/mo | A platform team governing an estate of 5–20 servers |
| Business | $149/mo | 250,000 calls/mo | Estate-wide governance with SIEM evidence and multi-team routing |
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
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.