JWT None Algorithm is a weak JSON Web Token configuration in which the token uses no digital signature. Attackers can exploit it if an application accepts unsigned tokens, so defenders must reject the none algorithm, enforce strict algorithm checking and verify signatures before trusting any claims.
What the none algorithm means for JWT security
A JWT signed with none is not protected by a digital signature, so the application must never treat its claims as trustworthy unless it has already rejected unsigned tokens. The danger is not the token format itself, but a validation path that accepts unauthenticated content as if it were verified.
That makes algorithm handling a security control, not a parsing detail. A robust implementation must separate token decoding from token acceptance, then enforce an allowlist of expected algorithms before any business logic uses the claims.
Why accepting unsigned JWTs is dangerous
When an application accepts the none algorithm, an attacker can forge identity, role, or session claims without possessing a signing key. That can convert a simple token parser into a full authentication bypass.
The core failure is trust inversion: the application reads claims first and validates later, or skips signature verification entirely. Once that happens, any downstream control that relies on the JWT, including user identity, role assignment, or tenant context, can be manipulated by the attacker.
How defenders should validate JWT algorithm handling
Defensive jwt validation should be explicit about the algorithm expected for each issuer or token profile. Do not infer trust from token structure alone, and do not allow the token header to choose an algorithm outside the server’s approved set.
For practical implementation guidance, review Token and Session Security Guide for JWT validation, token lifetime, revocation and replay controls. For workload and service-to-service trust models that rely on signed tokens and attestation, see Guide to SPIFFE and SPIRE.
Where token forgery is a realistic abuse path, Microsoft Storm-0558 key breach 2023 is a useful reminder that signature trust depends on key protection, key rotation and strict validation logic, not just on the presence of a JWT.
What compromise can look like after a none-algorithm bypass
If a forged JWT is accepted, the attacker may inherit whatever authority the token represents, from a normal user session to elevated application privileges. The practical effect is often silent impersonation, because the application believes the token is authentic and continues processing requests normally.
That means detection must look for impossible claim patterns, unexpected issuer or audience values, and tokens that succeed without a valid signature path. Post-incident review should also check whether session state, refresh flows, or cached authorization decisions were built on top of the forged token.
Risk and Threat Considerations
JWT none is high risk because it turns token integrity into an optional assumption. If any service accepts unsigned or improperly validated tokens, an attacker can fabricate claims and use them for impersonation, privilege escalation, or lateral movement within the application boundary.
Failure mechanism: The application trusts the token header or decoded claims before enforcing a strict algorithm allowlist and signature verification, so attacker-controlled input is accepted as authenticated identity.
Impact: Authentication bypass, forged roles or tenant context, unauthorized access, and downstream compromise of any workflow that treats the JWT as a source of truth.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | JWT validation and signature checks are part of authentication assurance. |
| Recommendation — Require signed-token verification and reject unsafe JWT algorithm handling before trusting claims. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | JWTs function as authenticators or bearer credentials that must be controlled and validated. |
| IA-7 — Cryptographic Module Authentication | Unsigned JWT acceptance defeats cryptographic proof of token authenticity. | |
| SI-10 — Information Input Validation | Rejecting unsafe JWT algorithms is a validation control over untrusted input. | |
| Recommendation — Enforce authenticated token issuance, verification and lifecycle controls for JWT-based access. Verify cryptographic authenticity of tokens before accepting identity or session claims. Validate JWT headers and claims against a strict allowlist before processing them. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Accepting none-algorithm JWTs breaks API authentication and enables forged access. |
| Recommendation — Reject unsigned JWTs and enforce server-side signature verification for API access. | ||
| MITRE ATT&CK | T1550 — Use Alternate Authentication Material | Forged JWTs are alternate authentication material used to impersonate a valid principal. |
| Recommendation — Detect and block misuse of stolen or forged authentication material in token flows. | ||
Practitioner Guidance
Why practitioners should care: Treat none as a prohibited configuration, not as an edge case to tolerate for compatibility. If a library or gateway can be configured to accept unsigned JWTs, that setting should be removed or blocked at the platform layer, because the safest validation code is the code that never reaches an unsafe acceptance state.
Common misunderstanding: Developers sometimes assume that checking token format, issuer or expiration is enough. Those checks do not compensate for missing signature verification, and they do not make unsigned claims trustworthy.
Practitioner takeaway: Enforce an explicit expected-algorithm policy, verify signatures before using claims, and test that the system rejects any token that tries to downgrade into none.
Related resources from NHI Mgmt Group
- How should security teams prevent JWT none algorithm abuse in authentication flows?
- How should security teams prevent JWT algorithm confusion in verification code?
- Why do JWT algorithm confusion attacks bypass normal authentication controls?
- Why does allowing the none algorithm create such a high authentication risk?