JOSE algorithms: alg and enc values for JWS and JWE

EdDSA

The polymorphic EdDSA identifier of RFC 8037, deprecated by RFC 9864 in favour of Ed25519 and Ed448.

With 'EdDSA' the curve comes from the key (crv: Ed25519 or Ed448), so a party cannot announce which curve it supports. RFC 9864 registers the fully specified names Ed25519 and Ed448 and marks 'EdDSA' Deprecated.

ES256

ECDSA on P-256 with SHA-256, the JWS algorithm most often used for signed JWTs with asymmetric keys.

A JWS signature with ES256 is the 64-byte concatenation of r and s, each padded to 32 bytes (RFC 7518 §3.4), not the DER structure OpenSSL and Java produce; converting between the two is a common source of 'invalid signature' errors — see the DER ⇄ raw converter.

RFC 9864 deprecates the polymorphic COSE identifier ES256 (−7) in favour of the fully specified ESP256 (−9); in JOSE the name ES256 already fixes the curve, so it is unaffected.

HS256

HMAC with SHA-256, a symmetric JWS algorithm: whoever can verify a token can also forge one.

HS256 is the only algorithm RFC 7518 makes required. Because the same secret signs and verifies, it suits a single service that issues and checks its own tokens. A short or guessable secret can be brute-forced offline from any token; RFC 7518 §3.2 requires a key at least as long as the hash output — 256 bits for HS256 — and it must be random.

ML-DSA-65

ML-DSA-65 (FIPS 204) for JWS, registered by RFC 9964 with the new AKP key type.

Post-quantum JWS keys use the Algorithm Key Pair key type (kty 'AKP'), whose 'pub' member holds the raw ML-DSA public key and 'alg' binds it to one parameter set. Signatures are 3,309 bytes, so tokens become several kilobytes long.

none

alg "none" marks an unsecured JWS — a token with no signature at all.

RFC 7518 §3.6 defines 'none' for contexts where integrity is provided by other means. Libraries that let the token's own header choose the algorithm have accepted forged tokens with alg 'none', the best-known JWT vulnerability (RFC 8725 §2.1); verifiers must reject it unless the application explicitly expects unsecured tokens.

RS256

RSASSA-PKCS1-v1_5 with SHA-256, the JWS algorithm of most OpenID Connect ID tokens.

OpenID Connect Core §15.1 requires providers to support signing ID tokens with RS256, which is why most ID tokens and JWKS endpoints use RSA keys. Its classic pitfall is algorithm confusion: a verifier that accepts HS256 for a key meant for RS256 can be tricked into using the public key as an HMAC secret (RFC 8725 §2.1). Pin the expected algorithm per key, as RFC 8725 §3.1 requires.

RSA1_5

RSAES-PKCS1-v1_5 key encryption for JWE, exposed to Bleichenbacher-style padding-oracle attacks.

A server that reveals in any way — error message, timing — whether the padding of a decrypted RSA1_5 key was valid lets an attacker decrypt content keys one query at a time. RFC 7518 marks RSA1_5 'Recommended-', likely to be downgraded; prefer RSA-OAEP-256 or ECDH-ES.