alg Header Parameter
The alg (algorithm) header parameter declares which cryptographic algorithm was used to sign the JWT. Common values include HS256, RS256, ES256, and PS256. Verifiers must compare alg against an explicit allowlist — never use the header value to dynamically select verification without constraints. Libraries should reject alg:none and unexpected algorithms before attempting signature verification. Implementations across Node.js, Python, Go, Ruby, and Java follow the same RFC standards, so concepts transfer directly between stacks. Security reviews should treat this as part of your full authentication threat model, not an isolated configuration detail. Document expected behavior for client teams so tokens are issued, stored, and validated consistently across services.
Why It Matters
alg is the centerpiece of algorithm confusion attacks. Attackers swap RS256 for HS256 and sign with the public key as an HMAC secret. Pin expected algorithms in code, ignore client-supplied preferences, and test with malicious tokens during security reviews. Getting this wrong often surfaces only after an incident, when forged or replayed tokens expose gaps in validation or secret handling. Platform teams should encode these rules in libraries, linting, and deployment checklists so individual services cannot drift silently. Pair technical controls with monitoring: log verification failures, track unusual token lifetimes, and alert on spikes in 401 responses.
Code Example
jwt.verify(token, secret, {
algorithms: ["HS256"],
issuer: "https://auth.example.com",
audience: "api"
});Related Terms
Related Tools
Related Articles
Frequently Asked Questions
Should I trust the alg header?
Use it only to select from your pre-approved algorithm list. Never accept arbitrary or none algorithms. Consult your JWT library documentation for exact option names, defaults, and error types. When in doubt, prefer stricter validation and shorter token lifetimes over permissive shortcuts.
What is alg none?
An unsigned token variant. Production systems must always reject tokens with alg none. Consult your JWT library documentation for exact option names, defaults, and error types. When in doubt, prefer stricter validation and shorter token lifetimes over permissive shortcuts. Test edge cases with expired, malformed, and wrong-algorithm tokens in CI before shipping auth changes.
Where is alg validated?
Before signature verification in your auth middleware or JWT library configuration. Consult your JWT library documentation for exact option names, defaults, and error types. When in doubt, prefer stricter validation and shorter token lifetimes over permissive shortcuts. Test edge cases with expired, malformed, and wrong-algorithm tokens in CI before shipping auth changes.