Reusing Someone Else's Session Token on a Shared Judge Endpoint

What a session token carries

A session token is a bearer claim: whoever presents it is, for the lifetime of the token, whoever the token says they are. It encodes identity, an expiry, sometimes an audience and a scope — and nothing else. The endpoint that accepts it does not verify the presenter; it verifies the token, then maps the token's claims onto permissions. That is the entire protocol: possession is identity.

The design implication is immediate. If someone else's token works for you, the system failed to bind the token to its owner — the claim travelled further than the identity it describes. Reuse is not a property of the token itself; it is a property of the binding, and binding is an issuance-time decision. Tokens can be bound to a client certificate, to a device fingerprint, to a network position, to an audience string; each binding narrows the set of presenters for whom the token will work.

The hardening catalogue is correspondingly standard: short lifetimes, so a leaked token dies quickly; audience and sender binding, so a token issued for one consumer is useless to another; rotation, so the standing set of valid tokens stays small; and anomaly detection, so a token that suddenly appears from a new context — a different IP, a different UA, a different timezone — is flagged before it is honoured.