EdDSA: Edwards-curve Signatures in a JWT
EdDSA is Edwards-curve signing, registered for JOSE by RFC 8037 with the curves Ed25519 and Ed448. It is deterministic, fast and compact, but support across JWT tooling is still uneven.
At a glance
- Algorithm
- EdDSA, Edwards-curve Digital Signature Algorithm
- Registered in
- RFC 8037, which extends the JOSE registries created by RFC 7518
- Implementation requirement
- Optional
- Key
- OKP key type with crv set to Ed25519 or Ed448. One alg name covers both curves.
- Signature size
- 64 bytes for Ed25519, 114 bytes for Ed448
- Verified in the decoder
- No. The decoder names the algorithm in its table and tells you it cannot verify it, rather than showing a misleading result.
In detail
EdDSA is the odd one out in the registry because the alg value does not name a curve. RS256 fixes RSA and SHA-256, ES384 fixes P-384; EdDSA fixes neither, and the curve comes from the key instead, where crv is Ed25519 or Ed448. That means a verifier cannot tell from the header alone which curve it will need, and the key has to be looked at.
Its appeal is practical. Signatures are deterministic, so there is no per signature random value to get wrong, which removes the failure mode that has broken ECDSA deployments. Keys are tiny, 32 bytes for an Ed25519 public key, signatures are 64 bytes, and both signing and verification are fast. RFC 8037 also defines the OKP key type these keys use in a JWK.
Support is the catch. EdDSA is optional in the JOSE registry, arrived years after the original algorithms, and is still missing or partial in some JWT libraries, gateways and browser cryptography implementations. An issuer that switches to it can find one component in the chain that cannot verify anything, so the algorithm is best introduced where you control both ends.
The decoder is one of those tools. It lists EdDSA in its algorithm name table, so a token signed with it decodes normally and every claim, expiry state and validation check works as usual, and it states plainly that this algorithm cannot be verified here. That is deliberate: an inspection tool that quietly skipped verification would be worse than one that says it cannot do it.
Examples
// Header: no curve here
{ "alg": "EdDSA", "typ": "JWT" }
// Public key as a JWK: the curve is here
{
"kty": "OKP",
"crv": "Ed25519",
"x": "11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"
}Sample key material. RFC 8037 defines the OKP key type and the Ed25519 and Ed448 curve values.
Things that catch people out
- Expecting the header to say which curve is in use. Only the key knows, so a verifier configured with an Ed448 key cannot check an Ed25519 signature.
- Rolling out EdDSA across an estate before checking every verifier. It is optional in the registry and support is genuinely patchy.
- Assuming a decoder that shows the payload has checked the signature. This one is explicit that EdDSA verification is not available here.
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 →ES256: ECDSA with P-256 and SHA-256 in a JWT
ES256 signs a JWT with ECDSA on curve P-256 using SHA-256. Signature format, why raw R and S beats DER here, and verifying with a public key.
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.
alg (Algorithm) Header Parameter in a JWT
The alg header names the algorithm used to sign a JWT. Why the accepted algorithms belong in configuration, and what the decoder does with the value.
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.
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.
Tools for this
- JWT Decoder Free online JWT decoder - decode and inspect JSON Web Tokens without sending them to a server