Which JWT algorithm is most secure in 2026?

EdDSA (Ed25519) is the modern best choice — RFC 8037 standard, 256-bit Curve25519, fast, deterministic, resistant to side-channel attacks, smaller keys and signatures than RSA. ES256 (ECDSA P-256) is a strong second choice with broad library support. RS256 remains widely used in OAuth/OIDC (Google, Auth0, Okta) but requires careful algorithm-confusion prevention. Avoid HS256 in distributed systems where any service compromise leaks the signing secret.

What is the alg=none vulnerability?

Many JWT libraries historically accepted tokens with `"alg": "none"` header — meaning no signature verification. An attacker forges arbitrary payload, sets alg to none, and the library accepts it. Modern libraries (jose 5+, jsonwebtoken 9+, PyJWT 2+) reject alg=none by default, but older versions are vulnerable. The 2015 disclosure (Tim McLean) hit Node.js, PHP, Python implementations simultaneously. Always upgrade and explicitly whitelist algorithms.

Why is RS256→HS256 confusion dangerous?

Servers using RS256 publish their public key. If the JWT library uses a single key parameter for both algorithms, an attacker can: (1) take the published public RSA key, (2) sign a JWT using HS256 with the public key as HMAC secret, (3) submit to server, (4) server uses public key as HMAC verification key — VALID signature. Mitigation: explicitly whitelist algorithms per kid (key ID); never pass a single key to a library expecting "auto-detect alg".

Should I store JWTs in localStorage or cookies?

HttpOnly cookies with SameSite=Strict are safer than localStorage. localStorage is accessible to any script — an XSS vulnerability anywhere on your origin steals the JWT. HttpOnly cookies are inaccessible to JavaScript. Tradeoff: cookies require CSRF defense (SameSite handles most cases; add CSRF token for high-stakes operations). Modern recommendation 2026: HttpOnly + Secure + SameSite=Strict cookies for primary tokens, optionally with refresh-token rotation.

How do I revoke a JWT before expiration?

Pure JWTs are not natively revocable — that's the design tradeoff for stateless verification. Three solutions: (1) short access-token expiration (5-15 min) with refresh tokens that ARE revocable in DB; (2) Redis denylist of revoked jti claims, checked on every request (adds DB round-trip); (3) versioned signing keys — rotate on compromise, all tokens signed with old key invalidated. Most production systems combine #1 (short exp) + #2 (denylist for emergency revocation).

Can I put sensitive data in a JWT?

No. JWT payload is base64-URL encoded — NOT encrypted. Anyone with the token can decode and read all claims. For sensitive data: (1) use JWE (encrypted JWT, RFC 7516) with separate signature wrapping JWS; (2) put only an opaque user ID in JWT and look up sensitive data server-side; (3) avoid putting PII (email, name, phone) in JWT — even non-secret data leaks if token is logged or cached.

What is jku spoofing?

The `jku` (JWK Set URL) header tells the server WHERE to fetch the public key for verification. If the server blindly trusts the header URL, an attacker provides a URL pointing to attacker-controlled key set. Server fetches attacker keys → trusts attacker tokens. Mitigation: whitelist allowed jku domains; never enable jku without strict allow-list; better, use `kid` (key ID) lookup against a server-side map and ignore jku entirely.

What is the recommended JWT expiration time?

Short-lived access tokens: 5-15 minutes for sensitive APIs, 60 minutes for typical web apps. Long-lived refresh tokens: 7-30 days with rotation on use. Mobile native apps may extend access tokens to 24 hours if combined with secure storage and refresh-token rotation. Never issue access tokens longer than 24 hours without revocation infrastructure (Redis denylist or short-rotating signing keys).

JWT Security 2026 — Algorithm Comparison, Vulnerabilities, Best Practices

Short answer: Use EdDSA (Ed25519) for new systems — fast, secure, modern. Use RS256 for OAuth/OIDC compatibility. Avoid HS256 in distributed systems. NEVER accept alg=none. The 12 most common JWT vulnerabilities are listed below with exploitation pattern + mitigation. Always upgrade libraries (jose 5+, jsonwebtoken 9+, PyJWT 2+) — older versions had alg=none bugs.

JWT signing algorithms — full comparison

Algorithm	Type	Key size	Sign / Verify speed	Recommended?	Notes
HS256	HMAC + SHA-256	256-bit shared secret	Very fast / Very fast	OK for monolith	Vulnerable if secret leaks; cannot be public
HS384/HS512	HMAC + SHA-384/512	384/512-bit secret	Fast / Fast	OK	Marginally more secure than HS256
RS256	RSA-PKCS1-v1_5 + SHA-256	2048-bit minimum (4096 preferred)	Slow / Fast	Common for OAuth/OIDC	Vulnerable to algorithm confusion if HS256 also accepted
RS384/RS512	RSA-PKCS1-v1_5 + SHA-384/512	2048-bit min	Slow / Fast	Same as RS256	Same vulnerability profile
PS256	RSA-PSS + SHA-256	2048-bit min	Slow / Fast	Better than RS256	PSS padding — provably more secure than PKCS1-v1_5
ES256	ECDSA P-256 + SHA-256	256-bit elliptic curve	Fast / Fast	Modern choice	Smaller signatures than RS256 (~64 bytes vs 256)
ES384/ES512	ECDSA P-384/P-521	384/521-bit	Fast / Fast	Modern choice	Higher security level
EdDSA / Ed25519	EdDSA Curve25519	256-bit	Very fast / Very fast	BEST modern choice	Resistant to side-channel attacks; deterministic; RFC 8037
none	No signature	N/A	N/A / N/A	🚨 NEVER ACCEPT	Famous "alg=none" vulnerability — many libraries had bug accepting unsigned tokens

12 common JWT vulnerabilities

Criticalalg=none acceptance

How: Server accepts JWT with `alg: "none"` header — no signature verification. Attacker forges arbitrary claims.

Mitigation: Reject `alg: none` at parsing layer; whitelist algorithms; never use library defaults

CriticalRS256→HS256 algorithm confusion

How: Server uses public RSA key for HS256 verification. Attacker uses public key as HMAC secret to forge tokens.

Mitigation: Whitelist algorithm per kid; never use a single key for both algorithms; validate alg explicitly

Criticaljku/x5u header spoofing

How: JWT header points to attacker-controlled URL for public key. Server fetches and trusts attacker key.

Mitigation: Whitelist allowed jku/x5u domains; never blindly fetch from header URL

Highkid path traversal

How: `kid` (key ID) used as filesystem path. Attacker uses `../../etc/passwd` or similar.

Mitigation: Treat kid as opaque identifier; lookup in pre-defined map only

Highkid SQL injection

How: `kid` concatenated into SQL query without parameterization.

Mitigation: Always parameterize kid lookups; use prepared statements

HighWeak HMAC secret (brute-forcible)

How: HS256 with secret < 256 bits or dictionary word — brute-forced offline.

Mitigation: Generate cryptographically random 256-bit minimum secrets; use a KMS

HighToken storage in localStorage (XSS)

How: XSS attack steals JWT from localStorage; no HttpOnly protection.

Mitigation: Store in HttpOnly cookies with SameSite=Strict; or use service worker isolation

MediumLong-lived tokens without revocation

How: JWT exp far in future; no way to revoke compromised tokens.

Mitigation: Short exp (5-15 min) + refresh tokens; revocation list (Redis denylist) for compromise

MediumMissing exp/nbf/iat validation

How: Library or custom code skips claim validation — accepts expired tokens.

Mitigation: Use library defaults (jose, jsonwebtoken latest); explicitly validate; clock skew ≤30s

MediumSensitive data in payload

How: PII or secrets in JWT payload — base64 not encryption.

Mitigation: Use JWE (encrypted JWT) for sensitive payloads; or omit and lookup server-side

MediumMissing aud (audience) validation

How: Token issued for service A accepted by service B.

Mitigation: Always validate `aud` claim matches expected audience

MediumCSRF via JWT in cookie without SameSite

How: JWT in cookie automatically sent with cross-site requests.

Mitigation: SameSite=Strict cookies; CSRF token defense-in-depth

Library comparison by language

Language	Library	Stars	Notes
Node.js	jose	6.5K	Modern, TypeScript-first, supports JWE, ESM
Node.js	jsonwebtoken	17K	Most popular, larger surface, alg=none deprecated 2025
Python	PyJWT	5.2K	Standard choice, default verify
Python	authlib	4.6K	OAuth/OIDC integrated
Java	jjwt	10K	Spring ecosystem standard
Java	nimbus-jose-jwt	650	Apache; corporate-grade
Go	golang-jwt/jwt	7K	Forked from dgrijalva/jwt-go after 2021 abandonment
Rust	jsonwebtoken	1.7K	Pure Rust, zero unsafe
Ruby	ruby-jwt	3.6K	Rails standard
PHP	firebase/php-jwt	7.6K	Laravel ecosystem default
C#/.NET	System.IdentityModel.Tokens.Jwt	N/A (Microsoft)	Built-in for .NET 6+
Browser	jose (web crypto)	6.5K	Same as Node version, uses Web Crypto API

JWT security best-practice checklist

Whitelist allowed algorithms (don't use library auto-detect)
Reject `alg: none` at parsing
Use Ed25519 or ES256 for new systems; RS256 for OAuth/OIDC compatibility
Generate HS256 secrets via crypto-random 256-bit minimum (use KMS in production)
Store tokens in HttpOnly + Secure + SameSite=Strict cookies
Short access-token exp (5-15 min) + refresh-token rotation
Implement Redis denylist for emergency revocation
Validate `aud` (audience) and `iss` (issuer) claims always
Validate `exp` / `nbf` / `iat` with ≤30 sec clock skew
Whitelist `jku`/`x5u` domains if used; treat `kid` as opaque identifier
Use JWE (RFC 7516) for sensitive payloads, not plain JWS
Log JWT events (issue, refresh, revoke) for forensic analysis
Pin minimum library versions: jose ≥5, jsonwebtoken ≥9, PyJWT ≥2.8

Related Bytepane resources

Sources: RFC 7515 (JWS), RFC 7516 (JWE), RFC 7518 (JWA), RFC 7519 (JWT), RFC 8037 (CFRG/EdDSA), OWASP JWT Cheat Sheet 2025, Tim McLean's 2015 alg=none disclosure, NCC Group JWT security review 2024-2025. Algorithm recommendations align with NIST SP 800-186 (2023, post-quantum considerations) and CFRG IRTF guidance. Always test JWT implementations with a security tool (jwt_tool, JWT Heartbreaker, ZAP JWT add-on) before production deployment.