JWT Analyzer — Token Forgery & Algorithm Confusion
Signature validation proves a token was signed with the right key. It says nothing about whether the key was stolen or the token was replayed. Issuance correlation and context binding are what close that gap.
Open in Red Team Toolkit — jwtJWT Analyzer — Token Forgery & Algorithm Confusion
Signature validation proves a token was signed with the right key. It says nothing about whether the key was stolen or the token was replayed. Issuance correlation and context binding are what close that gap.
Telemetry generated
| Log source | Field / identifier | What it shows |
|---|---|---|
| Application Auth Logs | signature_result / alg | Signature failures and algorithm mismatches. A token presenting alg=none or an algorithm the service does not issue (e.g. HS256 when the service uses RS256) is an immediate forgery indicator. |
| Access / API Gateway Logs | sub / src_ip / asn | Same subject (sub claim) appearing from a new IP or ASN within a short window. Legitimate users do not instantly teleport between geographic regions. |
| IdP Token Issuance Records | jti / iat / sub | The authoritative list of tokens actually issued. A token presented to your service that has no matching issuance record in the IdP is forged, regardless of how plausible its claims appear. |
| WAF / API Gateway | Authorization header | Header inspection for algorithm anomalies and malformed JWT structure before the token reaches application logic. |
Detection rules
(A) ALGORITHM ANOMALY — Confidence: VERY HIGH
Presented alg header differs from the algorithm this service issues.
Covers: alg=none bypass, RS256-to-HS256 confusion attack (signing with
the public key as an HMAC secret), and any other unexpected algorithm.
Action: reject immediately; log the raw header for forensics.
(B) ISSUANCE CORRELATION — Confidence: VERY HIGH
Token has no matching record in the IdP's token issuance log (matched
on jti or sub+iat combination). Requires IdP issuance logging to be
enabled — this is the single most important logging control for JWT
environments. A plausible claim set does not help a forged token pass
this check.
Action: reject; alert SOC; treat as active compromise until disproved.
(C) CLAIM ESCALATION
Subject (sub) presents a role or permission claim higher than the
directory record for that identity. Example: user account presenting
admin=true when directory shows admin=false.
Action: reject; alert; investigate whether the IdP was compromised or
the token was hand-crafted.
(D) IMPOSSIBLE CONTEXT SHIFT
Same token (matched on jti or sub+iat) presented from geographically
impossible locations within the token's validity window. Example: Paris
at 10:00 and Sydney at 10:05 on a 15-minute token.
Action: revoke token family; force re-authentication; alert.
(E) SIGNATURE FAILURE BURSTS
Repeated signature validation failures for the same sub within a short
window, indicating offline-cracked candidates being tested online.
Threshold: >5 failures for the same sub within 10 minutes.
Action: lock subject; alert; treat as active cracking attempt.Evasion & counters
Forging a perfectly plausible claim set so the token looks legitimate to any inspector.
Issuance correlation is the only reliable answer. If the IdP never issued a token with that jti or sub+iat combination, the token is forged regardless of how plausible its claims appear. Enable IdP issuance logging before deploying JWT authentication.
Stealing a valid token so signature checks pass and issuance correlation succeeds.
Context binding plus short expiry with refresh rotation. A stolen token used from the wrong IP, ASN, or device triggers the impossible-context-shift detection. Short lifetimes limit the replay window.
Using the token only from the victim's own egress IP so context checks pass.
Bind tokens to a device via mTLS or DPoP (Demonstration of Proof-of-Possession) so possession of the token string alone is insufficient. The attacker must also control the bound key material.
Rule tuning
Preventive control
Pin the accepted algorithm server-side and reject anything else including none. Use asymmetric RS256 or ES256 so no shared secret exists to crack or leak. Set short access-token lifetimes with refresh rotation. Bind tokens to devices via mTLS or DPoP so token theft alone is insufficient for replay.