Token Signing, and What "Token Forgery" Actually Means
Modern auth tokens are trusted because they're signed. Here is how signing works, what a signing key really is, and why stealing one means an attacker can mint valid identities at will.
A lot of modern authentication rests on signed tokens — a JWT in a cookie, an access token from an identity provider, an assertion in a federation flow. The system trusts these tokens because they're signed. Understanding what "signed" means, and what the signing key is, explains a rare but catastrophic class of compromise: token forgery.
Why tokens are signed
A token like a JWT carries claims inside it: who the user is, what they can do, when it expires. The problem is obvious — if the token just said "user: admin," anyone could write that. So the issuer signs it. Signing produces a cryptographic value, computed over the token's contents using a secret or private signing key, that can be verified by anyone holding the matching key (or public key) but produced by no one else.
The deal is: if the signature checks out, the token is genuine and untampered, because only the issuer's key could have produced it. So validators don't need to call back to the issuer or hit a database; they just verify the signature locally and trust the claims. That's efficient, and it scales — which is exactly why signed tokens are everywhere.
What the signing key is, really
The signing key is the root of that trust. It is not a password to one account; it is the authority that makes any token genuine. Whatever that key signs, the entire system accepts as real, without further question. That is its purpose and its danger.
Two common arrangements: a symmetric secret shared between issuer and validators, or — more robustly — an asymmetric key pair, where the issuer holds a private key and validators check signatures with the corresponding public key. Either way, possession of the signing (private/secret) key is possession of the power to issue identity.
What token forgery is
Token forgery is what happens when an attacker obtains the signing key. With it, they don't break into an account — they mint tokens. They write a token that says "user: anyone, permissions: everything," sign it with the stolen key, and present it. Every check the system performs passes, because the token is, by every cryptographic measure, genuine. There's no failed login to alert on, no brute-force pattern, no impossible travel. The authentication layer can't catch it, because the authentication layer is exactly what was counterfeited.
That's the nightmare property: a forged token is indistinguishable from a real one. The attacker isn't fighting your defenses; they've become the authority your defenses trust.
Two things make it worse in practice. First, scope confusion: if a validator fails to check which key signed a token, or what that key is allowed to vouch for, a key meant for one trust domain can be accepted in another — so a lower-value key forges higher-value tokens. Second, key sprawl: signing keys that end up in memory dumps, logs, backups, or source control are extractable, and a key that can leave its vault can be stolen.
How signing keys are protected
Because the key is the root of trust, protecting it is non-negotiable:
- Keep it in hardware. Signing keys belong in an HSM or equivalent, where the private material is non-extractable and never appears in memory, a log, or a crash dump. The single worst failure is a key that was extractable enough to leak.
- Validate the signer, every time. Check not just that a signature is valid, but that the right key signed it and that the key is authorized for what the token claims. Boundary checks between trust domains are load-bearing.
- Rotate keys. Regular rotation limits the blast radius of any single compromise and forces the machinery to handle key changes cleanly.
- Keep secrets out of debug paths. Memory dumps and logs move around for legitimate reasons; treat them as potential carriers of key material and scrub them before they cross any boundary.
- Plan for "the token was valid." Assume some intrusions will pass authentication cleanly. Detection then has to live downstream — anomalous use, claims that match no real sign-in — not in the login check.
The takeaway
A signed token is trusted because only the issuer's key could have made it; the signing key is therefore the authority that mints identity, not a credential to one account. Token forgery is what an attacker does once they hold that authority — and the only defenses are keeping the key physically unstealable, checking rigorously what each key is allowed to sign, and accepting that if the trust root fails, your only leverage is detection.