alg (Algorithm) Header Parameter in a JWT
alg names the algorithm that produced the signature. It is required, and it is written by whoever made the token, so a verifier uses it to check a decision it has already made rather than to make one.
At a glance
- Parameter
- alg (Algorithm)
- Defined in
- RFC 7515 section 4.1.1
- Value type
- String from the JSON Web Signature and Encryption Algorithms registry
- Required
- Yes. A JWS with no alg in its header is invalid.
- Trust level
- Read before anything has been verified, so it must be treated as untrusted input.
- In the decoder
- Shown in the header JSON and mapped to a name from a table of 14 algorithms, which also decides which verification path is offered.
In detail
The header travels inside the signing input, so it cannot be edited without invalidating the signature. That is true and it is not the point. The verifier reads alg before it has checked anything, which means at the moment of reading it is just a string the sender chose. Everything that has gone wrong with JWT verification historically comes from code that took an instruction from that string.
Two attacks follow from it. Setting alg to none asks the verifier to skip the check entirely. Changing RS256 to HS256 asks it to treat a published public key as an HMAC secret, which the attacker also has. Both work only against a verifier that decides how to check the token by reading the token, and both fail against one that decided in advance.
So the rule is short: hold the accepted algorithms in configuration, reject any token whose alg is not in that set before doing anything else, and bind the key material to its type so a symmetric operation cannot be attempted with an asymmetric key. Where an issuer publishes a key set, the entry there carries its own alg, and matching the two is stronger than trusting either alone.
The decoder shows alg in the decoded header and looks it up in a table of fourteen names, from HS256 through the RSA, ECDSA and PSS families to EdDSA and none. That mapping decides what it offers next: a secret box for the HMAC algorithms, a PEM public key box for the rest, and a plain statement for EdDSA and none, which it cannot verify. Its validation list also flags a missing alg and an alg of none.
Examples
// Issued
{ "alg": "RS256", "typ": "JWT", "kid": "2024-06-key" }
// Rewritten by an attacker, signed with the public key as an HMAC secret
{ "alg": "HS256", "typ": "JWT" }
// Rewritten again, no signature at all
{ "alg": "none", "typ": "JWT" }A verifier configured to accept only RS256 rejects both rewrites before looking at any key.
Things that catch people out
- Passing the header algorithm into the verification call. That is the whole vulnerability class in one line of code.
- Accepting a list of algorithms wider than you use. Every extra entry is another way in, so accept exactly what your issuer emits.
- Assuming a library is safe by default. Some accept whatever the header says unless you pass an explicit list of permitted algorithms.
Try it: JWT Decoder
Paste a token to decode the header and payload, read the claims and expiry, and verify the signature in your browser. Nothing is uploaded.
JWT Decoder
LOCAL · Browser-OnlyDecode and inspect JSON Web Tokens without sending them to a server
Related JWT claims and algorithms
All jwt claims and algorithms →none: The Unsecured JWT Algorithm
The none algorithm means a JWT carries no signature at all. How the alg none attack works, what to configure, and how the decoder handles such a token.
kid (Key ID) Header Parameter in a JWT
The kid header says which key signed a token. How rotation depends on it, why the value must be a lookup and never a path, and decoder behaviour.
HS256: HMAC with SHA-256 in a JWT
HS256 signs a JWT with a shared secret using HMAC and SHA-256. Key sizing, the algorithm confusion attack, and verifying one in your browser.
typ (Type) Header Parameter in a JWT
The typ header declares the media type of a token. Why at+jwt exists, how typ prevents cross token confusion, and what the decoder flags.
cty (Content Type) Header Parameter in a JWT
The cty header describes the payload rather than the token. How the value JWT signals a nested token, and when nesting is actually worth it.
jku (JWK Set URL) Header Parameter in a JWT
The jku header points at a JWK Set URL for the signing key. Why following it blindly gives an attacker both forgery and SSRF, and safe handling.
Tools for this
- JWT Decoder Free online JWT decoder - decode and inspect JSON Web Tokens without sending them to a server