JSON Web Token (JWT)

A JWT is a small, self-contained, tamper-evident piece of data, usually a set of claims like "user ID 42, expires at 3pm, issued by auth.example.com": that anyone holding the right public key can verify without asking the issuer. Pull one apart and it's three parts separated by dots:

header.payload.signature

Each part is base64url-encoded JSON (the signature is binary, so it's base64url-encoded raw bytes). The header names the signing algorithm and token type; the payload carries the actual claims, standard ones like iss (issuer), sub (subject), exp (expiry), plus whatever custom claims an application needs; the signature is computed over the first two parts using the issuer's private key. Anyone with the issuer's public key, typically fetched from a JWKS endpoint, see that entry, can recompute the signature and confirm the token hasn't been altered, without ever contacting the issuer at verification time. That "verify locally, no phone-home" property is the entire reason JWTs exist: it's what makes stateless, horizontally-scaled authentication practical.

It's worth being precise about what a JWT signature actually guarantees: integrity and authenticity (this hasn't been tampered with, and it really came from whoever holds the private key), not confidentiality. A standard signed JWT is not encrypted; anyone who intercepts it can read every claim inside it in plain text. (A separate, less common format, JWE, JSON Web Encryption, handles the encrypted case.)

Where it comes from

JWT is RFC 7519, finalized in May 2015 by the IETF's JOSE working group. Its authors, Michael B. Jones, John Bradley, and Nat Sakimura, are, by this point in the Lexicon, a familiar trio: they wrote or co-wrote most of the standards this category covers, from JWKS to PKCE to large parts of OpenID Connect itself. JWT itself builds on even older work, JSON, and the general idea of self-describing signed tokens goes back further still, but RFC 7519 is the document that standardized this exact wire format. Solidus designed none of it.

Solidus today

Solidus mints real JWTs today at auth.solidus.network: EdDSA-signed ID Tokens (via the internal @solidus/jwt package) and ES256-signed, DPoP-bound Solid-OIDC access tokens (via jose, for compatibility with Community Solid Server's verifier, see DPoP for why two different signing keys are involved). @solidus/jwt itself is workspace-internal, not a package you can npm install on its own; the JWTs it produces are what you'll actually receive from a live login at auth.solidus.network, which runs on Solidus's public testnet against did:solidus identities: there is no mainnet, and no independent audit of this code has happened.

See also

JWKS is how a verifier gets the public key a JWT's signature checks against. OIDC is the protocol that standardized the JWT-shaped ID Token. DPoP adds a binding on top of a JWT so it can't be replayed by whoever steals it. Ed25519 / EdDSA is the signature algorithm Solidus's ID Tokens use.