Cybersecurity glossary
What are JSON Web Token (JWT) Attacks?
Learn what JWT attacks are, including alg:none, weak secrets, key confusion, and claim tampering, and how to validate tokens safely to prevent authentication bypass.
Definition
JWT attacks are techniques that abuse flawed creation, signing, encryption, or validation of JSON Web Tokens—such as accepting unsigned tokens, guessing weak HMAC secrets, confusing key types, or trusting mutable claims—to impersonate users or escalate privileges.
Why JWT attacks matter
JSON Web Tokens pack identity claims into a compact, portable string. That convenience spreads tokens across browsers, mobile apps, microservices, and APIs. When validation is incomplete, attackers do not need to steal a password—they forge or tweak a token the application already trusts.
JWT attacks are therefore mostly authentication logic failures dressed as cryptography. Libraries can be used safely, but defaults and custom parsers historically left room for alg confusion, weak secrets, and missing claim checks.
Common JWT attack techniques
alg:none / unsigned tokens
Tokens declare no signature and libraries accept them, letting attackers set arbitrary claims.
Weak HMAC secrets
HS* tokens signed with guessable secrets are cracked offline, then freely minted.
Algorithm / key confusion
Verification uses the wrong cryptographic primitive for the presented key material.
Claim tampering without verify
Applications decode the payload and trust roles without verifying the signature first.
kid injection
Attackers manipulate key IDs to point verifiers at attacker-controlled keys or files.
Replay of long-lived tokens
Stolen JWTs remain valid for hours or days without revocation or binding controls.
How a typical JWT attack unfolds
Obtain a sample token
Capture a JWT from a browser, mobile app, or documented API response.
Inspect header and claims
Decode the base64url header/payload to learn alg, kid, iss, aud, and role fields.
Probe validation weaknesses
Try none, algorithm swaps, claim edits, and secret guessing against the verifier.
Forge a privileged token
Mint a token with elevated roles or another user’s subject if checks fail.
Call authenticated APIs
Present the forged bearer token to reach protected resources.
Persist access
Reuse long-lived tokens or repeat the forge path until defenses improve.
High-risk validation mistakes
| Mistake | Result |
|---|---|
| Decode without verify | Anyone can edit claims in a base64 payload |
| Allow arbitrary alg from header | Attackers choose the verification mode that helps them |
| Share weak symmetric secrets | One leak or guess compromises all HS* tokens |
| Skip aud/iss checks | Tokens from other apps or environments are accepted |
| No exp enforcement | Stolen tokens live forever in practice |
Defenses that stop JWT attacks
- Use well-maintained libraries; verify signatures before trusting any claim.
- Allowlist algorithms explicitly (for example, RS256 only) and reject none.
- Use strong secrets for HMAC or—preferably—asymmetric keys with proper key management.
- Validate iss, aud, exp, nbf, and tenant/user claims required by your authorization model.
- Keep access tokens short-lived; use refresh rotation and server-side revocation where needed.
- Treat kid and jku/x5u as untrusted unless cryptographically constrained and allowlisted.
- Never store sensitive secrets in JWT payloads expecting privacy without JWE and careful design.
- Test for token forgery in security reviews the same way you test password auth bypasses.
The practical takeaway
JWT attacks succeed when applications treat tokens as trusted blobs instead of authenticated assertions. The cryptography is only as strong as verification, key management, and claim checks.
Verify first, allowlist algorithms, validate claims, expire quickly, and assume every bearer token is portable malware until proven otherwise.
Related security terms
JWT (JSON Web Token)
The token format these attacks target.
Broken Authentication
The broader failure class that insecure JWT handling often causes.
OAuth 2.0
An authorization framework that commonly issues JWT access or ID tokens.
Session Hijacking
Related account takeover when tokens are stolen rather than forged.
Frequently asked questions
What are JWT attacks in simple terms?
JWT attacks trick an application into accepting a fake or altered login token. If the app does not verify signatures and claims correctly, attackers can become another user without the real password.
What is the JWT alg:none attack?
Some libraries historically accepted tokens with algorithm set to none and no signature. Attackers stripped the signature and forged claims. Modern libraries must reject none unless explicitly and safely configured—which they should not be for auth.
Can weak HMAC secrets be cracked?
Yes. If HS256 tokens are signed with a short or common secret, attackers can brute-force the secret offline and mint valid tokens.
What is JWT key confusion?
A classic issue is treating an RSA public key as an HMAC secret, allowing attackers to sign tokens with the publicly known key. Libraries must bind expected algorithms to key types.
Does using JWT automatically make auth secure?
No. Security depends on secret/key management, algorithm allowlists, claim validation, short lifetimes, and correct audience/issuer checks.
What claims should always be validated?
At minimum: signature, algorithm, issuer (iss), audience (aud), expiry (exp), and any tenant/user identifiers your authorization depends on. Reject unexpected algorithms.
Are encrypted JWTs (JWE) immune?
Encryption protects confidentiality of claims but does not replace authentication of the token or careful validation. Misconfiguration still causes failures.
References
Explore authoritative guidance and frameworks related to json web token (jwt) attacks.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.