A stolen bearer token survives your region, client and protocol blocks — which control class remains?
answer
- presentation is the whole proof
- possession equals authority
- make possession insufficient
- binding removes, lifetime prices
- rotation changes the instance only
basics
~20 sOne precondition is left: the token is accepted from whoever presents it. The control class that removes it is proof of possession - binding the credential to a key the presenter must prove they hold.
solid answer
~50 sEvery block you listed sits on the attacker's side of the exchange, so each costs a configuration change: another region, another client string, whichever access surface the tenant still exposes. What none of them touch is the property the technique actually runs on — the credential is a *bearer* credential, meaning presentation alone is treated as proof. Remove that and the copied token is worthless. In practice that is proof-of-possession issuance: bind the token to a key the legitimate client holds and require a signature over each request, as with mutual-TLS-bound tokens (RFC 8705) or DPoP (RFC 9449). A thief who copies the token without the private key cannot use it. Where binding is genuinely unavailable, shortening the lifetime and cutting the rights the credential carries are the fallback — but be clear those price the attack down; they do not remove the precondition.
code
text · 11 linesRequest A — bearer credential, copied
Authorization: Bearer eyJ... <- accepted because it was presented
User-Agent: <anything> <- swappable, free
Source: <any region, via proxy> <- swappable, cost of a host
Surface: <any endpoint accepting it> <- swappable, free
Request B — possession-bound credential
Authorization: DPoP eyJ...
DPoP: <proof signed by the private key the token was bound to>
...
-> a holder who copied only the token has no key, so the replay failsgo deeper
Know what bearer means: whoever presents the credential is served, so a copy is a working credential. That single fact explains why the region and client blocks changed nothing.
Be ready to derive the control class from the precondition out loud — possession equals authority, therefore make possession insufficient — and to name binding schemes as the removal and lifetime as the price.
Show judgment where binding is unavailable: short-lived credentials issued from a secret the client never holds, reduced scope, and an explicit statement that the path remains bearer rather than a claim that it is fixed.
Own the issuance model rather than the incident: decide which credential classes your platform is allowed to mint at all, and accept that constraining that set is what stops this recurring across every integration you have not seen yet.
## What "bearer" actually means A bearer credential is one where **presentation is the whole proof**. The validator checks that the artefact is well formed, unexpired, correctly signed by its issuer and scoped to this audience — and then serves whoever sent it. It does not, and cannot, ask whether the sender is the party the credential was issued to. That is not a bug in any particular product; it is the definition of the credential type, and it is why a copied bearer token is a working credential in anyone's hands. Every other fact about the replay is decoration. The client library, the user agent string, the source address, the access surface — all of them are the sender's to choose, and choosing differently costs a setting or the rent on a host. So a sequence of blocks aimed at those produces a sequence of small delays and then the same outcome. ## Deriving the control class from the precondition The derivation is mechanical once the precondition is named. The precondition is *possession equals authority*. Therefore the control class is anything that makes possession insufficient. **Proof of possession (binding).** The token is issued against a key pair whose private half stays with the legitimate client. Every request carries a fresh signature over that request made with the private key, or the connection itself is authenticated with the client's certificate and the token records the certificate's thumbprint. Two published schemes do this for OAuth-style credentials: mutual-TLS client-certificate-bound access tokens (RFC 8705), where the token is bound to the TLS client certificate, and DPoP (RFC 9449), where the client sends a signed proof header alongside the token. In both, copying the token alone yields nothing, because the thief has the artefact and not the key. This is a **removal**: the property that made the copy valuable is gone. **Short lifetime.** A credential that lives minutes rather than months means the copy is stale before it can travel. This is a **price**, not a removal — a credential stolen and used in its first minute replays perfectly. What it does destroy is any model built on the credential still working later, which matters a great deal against resale. **Scope reduction.** Cutting the rights the credential carries changes what a successful replay reaches. It does not touch replayability at all; it changes the consequence. Worth doing, wrong to present as the answer. ## Why rotation is not on this list Rotation replaces the instance and leaves the class untouched. The new token is still accepted from whoever presents it, so the next copy replays exactly as the last one did. Rotation on a schedule is really a lifetime argument wearing different clothes: it bounds how long one theft stays useful. It never converts possession into something the thief must also prove. ## When binding is unavailable Some integrations cannot hold a private key: a third party's platform that only speaks bearer, an appliance with no key store, a partner who will not change their client. Two honest moves remain. Issue short-lived credentials derived from a longer-lived secret that lives somewhere the client cannot leak, so the artefact in flight is the cheap one. And reduce what the credential can reach, so a replay lands somewhere smaller. Then write the residual down explicitly: *this path remains bearer; we priced it, we did not remove it.* An architect who says that is trusted more than one who reports the path mitigated. ## Reading the whole answer back The shape of a good answer here is three sentences. Name the swappable set and price it at roughly zero. Name the single surviving precondition in the language of the credential type, not the language of the incident. Then name the control class that makes that precondition false, and separate cleanly the controls that remove it from the ones that merely shorten the window. Interviewers are listening for that separation — it is the difference between someone who collects controls and someone who derives them.
- Why is rotating the secret not the same as removing the precondition?Rotation replaces the instance, not the class. The new credential is still accepted from whoever presents it, so the next copy replays exactly as the last one did. Rotation bounds how long a single theft stays useful, which is a lifetime argument in disguise; it never makes possession insufficient.
- Is a shorter lifetime a removal or a price?A price. It multiplies how often the operator must re-steal, which is enough to break some business models, but a credential used in its first minute still replays perfectly. Only binding presentation to something the thief did not obtain makes the copy worthless.
- The integration cannot hold a private key. Now what?Then binding is unavailable on that path and you are left with lifetime and scope: issue short-lived credentials from a longer-lived secret the client never sees, and cut the rights so a replay reaches less. Record plainly that the precondition remains and you priced it down rather than removed it.
saying these in an interview costs you the question
- Names the legacy protocol block as the mitigation
- Says rotating the secret removes the weakness
- Calls source-address restriction a fix for replay
- Confuses a shorter lifetime with removing bearer semantics
- Treats scope reduction as if it stopped replay