A valid token in the wrong place
A Socratic walk-through of a valid token in the wrong place — reasoned out one step at a time, not lectured.
The question we started with
THE QUESTION #Why is a token that passes every check still the wrong one to accept?
A service receives a signed token. It verifies the signature against the issuer's published key: correct. It checks the expiry: still live. It reads the claims: a real user, with the scope this endpoint requires. Every check passes, and the service grants access.
It may still have made a serious mistake. That is uncomfortable, because it suggests validity is not the same thing as acceptability — and if so, the missing check is not a cryptographic one, which is exactly the kind that gets left out. So what property could a perfectly valid token be lacking?
Reasoning it through
REASONING #Begin with what a signature actually attests. It says: this issuer produced this document, and it has not been altered since. That is all. It is a statement about origin and integrity, and it is silent on the question of who was supposed to receive the document.
Now consider what that permits. Suppose you run a small service and users sign in to it with a well-known identity provider. You receive access tokens for your service. Suppose a much more valuable service trusts the same provider. If that service checks only signature, expiry and scope, then a token minted for you verifies perfectly there — and you, or anyone who compromises you, can present it and be served.
Nothing was forged. The token is genuine. It was simply spent somewhere it was never meant to be spendable. The missing property is audience: the statement of which party the token was issued to be presented to, carried in the aud claim of a JSON Web Token and checked by the recipient against its own identifier.
This generalises into an old pattern with a good name. A confused deputy is a component that holds authority and acts on a request without checking whether the requester was entitled to that authority. A resource server that accepts any validly signed token is a deputy in exactly this sense: it is willing to use its own privileges on behalf of anyone who arrives holding a document from a source it trusts.
So what is the full set of checks? Verify the signature, and verify the issuer — iss must be a party you actually trust, not merely one whose key you happen to have. Check aud against your own identifier. Check exp and nbf. Check scope against the operation. And pin the algorithm: accept only the algorithms you expect, since the header of a JWT is chosen by whoever presented it. Two historical attacks make that concrete: alg: none, where a library was persuaded to treat an unsigned token as verified, and RS256-to-HS256 confusion, where an attacker re-signs a token symmetrically using the issuer's public key as the HMAC secret, since that key is published by design. Both are old, both were widely fixed, and both illustrate the same lesson — do not let the credential dictate how it will be examined.
Which points at the principle underneath all of it. Every check on the list is asking "is this document authentic?" except two — audience and issuer — and those are asking "was this document meant for me?" Authenticity is a property of the token alone. Appropriateness is a property of the token in a place. You cannot determine the second by inspecting the first more carefully, however rigorously you do it.
There is a request-time counterpart to this. When a client asks for a token it can name the resource it intends to use, so the authorization server can mint an audience-restricted token rather than a universal one — the resource-indicators mechanism of RFC 8707. Narrow issuance and strict acceptance are two halves of one discipline, and each is weaker alone.
The analogy
THE ANALOGY #A passport is an authentic document and a bank will not accept it as a cheque. Nothing about it is forged, expired, or in doubt; the state that issued it stands behind every word. It is simply not addressed to that counter, and the teller's job includes noticing that the genuineness of a document says nothing about whether this is the place to present it.
a passport and a cheque look obviously different, whereas two tokens for different audiences are byte-similar structures from the same issuer — the distinguishing information sits in one claim that a service must deliberately read, and the mistake is invisible rather than absurd.
Clarifying the model
THE MODEL #Three refinements.
First, "we trust the issuer" is not a security position. Trusting an issuer means trusting statements it made to you. Extending that to statements it made to somebody else is the error, and phrasing it as trust is what makes it sound reasonable.
Second, scope and audience are different axes and neither substitutes for the other. Scope says what may be done; audience says where. A token with a modest scope presented at the wrong service can still be the wrong token, and a correctly addressed token with an over-broad scope is a different failure entirely.
Third, this is not only about attackers. The commonest form is internal and accidental: services in one estate, all trusting one provider, passing tokens between themselves for convenience. Every hop that forwards a token it received is a deputy taking a document not addressed to it, and the resulting authority is impossible to audit precisely because everything is technically valid. Exchanging the token for a correctly addressed one is the fix.
A picture of it
THE PICTURE #How to readThe horizontal axis is everything a signature and expiry check can tell you; the vertical axis is the question those checks never ask. Most implementations only measure horizontally, which means they cannot tell the top-right quadrant from the bottom-right one — and the bottom-right is the dangerous quadrant, holding tokens that are entirely genuine and entirely misaddressed. The two left quadrants are the easy cases everybody already handles.
What became clearer
WHAT CLEARED #Verification answers whether a credential is real; it cannot answer whether it is yours to accept. Those are separate questions on separate axes, and a service that asks only the first will confidently admit perfectly authentic tokens minted for somebody else — which is why the audience claim, unglamorous as it is, is doing as much work as the signature.
Where to go next
ONWARD #- Token exchange as the disciplined alternative to forwarding a token you received.
- Sender-constrained tokens, which add "who may present this" to "who may receive it".
- The confused-deputy problem in its original 1988 form, and why capabilities were proposed as the answer.
Key terms
TERMS #| Term | What it means |
|---|---|
Audience (aud) | the JWT claim naming the recipient a token is intended for; the recipient must check it against its own identifier. |
Issuer (iss) | the claim naming the party that minted the token. |
| Confused deputy | a privileged component induced to use its authority on behalf of a party that lacked it. |
| Algorithm confusion | an attack in which a verifier is persuaded to use an unintended signature algorithm, such as verifying an RSA-signed token as an HMAC. |
| Resource indicators (RFC 8707) | a mechanism letting a client request a token restricted to a named resource server. |
Every term the collection defines is gathered in the glossary.