Token audience: stop one leaked token opening every server

Evidence label: deterministic synthetic model. This page runs a small JavaScript model of OAuth tokens in an MCP deployment: 40 synthetic users run sessions of tool calls against four MCP servers, tokens are issued, refreshed and stepped up according to your settings, and an attacker replays any token it captures from a compromised server or a leaked log. It does not contact any authorization server or MCP server; every number is a calculated estimate that makes the audience, scope and lifetime trade-offs visible.

Play the lab

How to play

Toggle whether the client sends a resource indicator, whether servers validate audience, and whether the orders server forwards client tokens to the upstream payments API. Choose broad scopes or challenge-and-step-up, set the access token lifetime, and decide whether refresh tokens are issued and rotated. Then inject a Compromised server, Tokens in a debug log or a Write-heavy week. Every change re-runs the same synthetic day with the same seed, so differences come from your change; use New random seed to confirm a fix holds.

Each mission loads a broken configuration and earns up to three stars for meeting its goal efficiently, for example with fewer consent prompts or less token endpoint load.

What the model assumes

Each user has four to eight sessions a day with four to ten calls a few minutes apart; 20% of calls go to the analytics server and 25% of calls to orders and files are writes (60% in the write-heavy week). Without a resource indicator the AS issues one broad token per user; with it, one token per server. A first token, an expired token without a usable refresh token, or a step-up needs an interactive consent, and 2% of users abandon a consent prompt. The compromised server replays every token it receives within minutes; the leak exposes 5% of issued tokens, and half of their refresh tokens, to an attacker who reads the log after an exponentially distributed delay averaging 30 minutes. With rotation, a stolen refresh token yields at most one extra lifetime before reuse detection revokes it.

What it cannot tell you

Real deployments add single sign-on that suppresses some consent prompts, token introspection caches, clock skew, sender-constrained tokens and revocation endpoints, none of which are modelled. Attackers are also smarter than a fixed replay loop. Use the lab to see how the controls compose, then verify your own clients and servers against the specification's normative requirements.

Read the full explanation

All AI in Production labs · Lab catalog

Views are my own and do not represent any employer, past or present.