Cybersecurity glossary
What is JWT alg none?
Learn what the JWT alg:none attack is, why some verifiers historically accepted unsigned tokens, how attackers forge claims, and how to permanently reject none in authentication.
Definition
JWT alg:none is an authentication bypass technique where a token advertises the none algorithm and carries no signature; vulnerable verifiers accept the crafted claims as trusted, allowing attackers to impersonate users without cryptographic proof.
Why alg:none still matters
The most infamous JWT failure is also the simplest: accept a token that openly declares it has no signature. JWT alg:none abuses that path so attackers rewrite claims without needing keys, secrets, or cryptanalysis.
Even though modern libraries usually block it, the pattern remains a must-test control. One permissive verifier in a microservice mesh is enough to reopen account takeover.
What makes none dangerous
No cryptographic barrier
Forgery requires only JSON editing and base64url encoding—no key material.
Looks structurally familiar
Tokens still resemble header.payload.signature, so naive parsers accept them.
Header is attacker-owned
alg is not authenticated until a real signature is verified with policy.
High impact
Any claim used for identity or roles can be set to attacker-chosen values.
How an alg:none exploit unfolds
Obtain any sample JWT
Capture a bearer token to learn claim names and expected shape.
Decode the payload
Inspect subject, roles, tenant, and expiry fields worth elevating.
Rewrite claims
Set privileged identity attributes while keeping a plausible structure.
Set alg to none
Change the header algorithm and clear the signature segment.
Replay against the API
Send the unsigned token to endpoints that perform authentication.
Confirm privileged access
If accepted, the verifier is treating unsecured JWS as authenticated.
Secure vs vulnerable verification
| Check | Vulnerable behavior | Secure behavior |
|---|---|---|
| Algorithm policy | Trusts header alg including none | Allowlists RS256/ES256/etc only |
| Empty signature | Accepted when alg is none | Rejected for auth tokens |
| Library mode | Unsecured JWS enabled | Unsecured mode disabled |
| Regression tests | None present | none tokens must return 401 |
Hardening against unsigned JWTs
- Explicitly disallow none in every JWT verifier and gateway plugin.
- Prefer libraries that require algorithms at construction time.
- Reject tokens with missing or empty signature segments for auth use.
- Centralize verification so microservices do not reimplement parsers.
- Include alg:none cases in unit, integration, and penetration tests.
- Alert on repeated none-algorithm presentation in auth logs.
- Upgrade legacy JOSE dependencies known for permissive defaults.
- Document that unsecured JWS is forbidden in authentication standards of the org.
The practical takeaway
JWT alg:none is unsigned trust. If a verifier accepts it, authentication is theater.
Disable unsecured JWS everywhere, allowlist real signing algorithms, and keep automated tests that prove none tokens never authenticate. Pair this control with broader algorithm-confusion and signature-bypass defenses.
Related security terms
JWT Algorithm Confusion
Broader class of algorithm-selection abuses that includes related forgeries.
JWT Signature Bypass
Other ways applications accept tokens without valid signatures.
JSON Web Signature (JWS)
The signed format authentication systems should require.
JSON Web Token (JWT) Attacks
Overview of common JWT exploitation patterns.
Broken Authentication
The account-security failure class this attack produces.
Frequently asked questions
What is JWT alg:none in simple terms?
It is a trick where the token says “I am not signed” and a buggy server still trusts it. Attackers edit the user ID or role fields and walk in without a real signature.
Is none a real JOSE algorithm?
JOSE historically defined none for unsecured JWS. It must never be accepted for authentication or authorization decisions.
Do modern libraries still allow none?
Most mainstream libraries reject none by default, but custom parsers, misconfigured options, or older dependencies can still accept it.
What does a none token look like?
Typically three segments where the header declares alg none and the signature segment is empty or omitted in vulnerable implementations that still parse it.
How do I prevent alg:none?
Allowlist only required signing algorithms, disable unsecured mode explicitly, and add tests that send none tokens and expect rejection.
Is stripping the signature enough for attackers?
Against vulnerable verifiers, yes: change claims, set alg to none, and remove the signature. Secure verifiers reject that input immediately.
Does encryption (JWE) stop alg:none?
Not automatically. You still need correct validation of the authenticated structure you ultimately trust.
References
Explore authoritative guidance and frameworks related to jwt alg none.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.