JWT
/dʒɒt/ · Abbreviation · Security & Infosec · Origin: 2015
Definitions
JWT, or JSON Web Token, is a compact, URL-safe token format for securely transmitting claims between parties. A JWT consists of three Base64-encoded parts separated by dots: a header specifying the signing algorithm, a payload containing claims (key-value pairs of data such as user ID, roles, and expiration time), and a signature that verifies the token has not been tampered with. JWTs can be signed using symmetric algorithms like HMAC or asymmetric algorithms like RSA and ECDSA. They are widely used for authentication and authorization in web applications, particularly in stateless architectures where the server does not store session data. After a user logs in, the server issues a JWT that the client includes in subsequent requests, typically in the Authorization header. Because the token is self-contained, any service with the signing key can validate it without querying a central database. Care must be taken with token expiration, storage, and revocation to avoid security pitfalls.
In plain English: A small, encoded package of information (like your user ID and permissions) that a server gives you after login, which you send back with every request to prove who you are.
Example: "We store the user role in the JWT claims, but please, for the love of all that is holy, don't put anything secret in there — it's base64, not encryption."
Origin Story
The self-contained token that carries its own passport
**JSON Web Token** (JWT, pronounced "jot") was formalized by **Michael B. Jones**, **John Bradley**, and **Nat Sakimura** in RFC 7519, published in May 2015. The concept emerged from the need for a compact, URL-safe way to transmit claims between parties — essentially a digitally signed JSON object that could serve as a self-contained authentication token.
Before JWTs, session management typically required server-side state: the server issued a session ID, stored session data in memory or a database, and looked it up on every request. JWTs inverted this: the token itself contained all the necessary information (user ID, permissions, expiration), signed with a secret key. The server could verify the token without storing anything, making JWTs ideal for stateless, distributed architectures.
JWTs became enormously popular but also enormously controversial. Security researchers have cataloged numerous pitfalls: the `alg: none` vulnerability, key confusion attacks between HMAC and RSA, and the difficulty of token revocation (since the server stores no state, you can't easily invalidate a token before it expires). The debate over whether JWTs are appropriate for session management continues to this day.
Coined by: Michael B. Jones, John Bradley, Nat Sakimura
Context: RFC 7519, May 2015
Fun fact: The official pronunciation is 'jot,' rhyming with 'dot,' as specified in the RFC. Most developers pronounce it as three letters: J-W-T. Both camps are fiercely devoted to their pronunciation, creating a mini holy war reminiscent of GIF vs. JIF.