Understanding JSON Web Tokens (JWT)

What Exactly is a JSON Web Token?

A JSON Web Token (JWT), pronounced "jot", is an open industry standard (RFC 7519) that defines a compact and self-contained method for securely transmitting information between parties as a JSON object. This information can be trusted and verified because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

The Three Pillars of a JWT

When you look at a raw JWT, it appears as a long, seemingly random string of characters. However, if you look closely, you will see two periods (.) dividing the string into three distinct sections. These sections are the Header, the Payload, and the Signature.

1. The Header

The header typically consists of two parts: the type of the token (which is logically "JWT") and the cryptographic signing algorithm being used, such as HMAC SHA256 (HS256) or RSA (RS256). This JSON object is then Base64URL encoded to form the first part of the JWT.

2. The Payload

The second part of the token is the payload, which contains the "claims". Claims are statements about an entity (typically, the authenticated user) and additional metadata. There are three classifications of claims:

• Registered claims: Predefined claims like iss (issuer), exp (expiration time), and sub (subject).
• Public claims: Custom claims defined by developers, which should be registered in the IANA JSON Web Token Registry to avoid collisions.
• Private claims: Custom claims created to share information specifically between parties that agree on using them (e.g., user_role or department_id).

The payload is also Base64URL encoded to form the second part of the JWT. Note that while the payload is protected against tampering by the signature, it is not encrypted. Anyone can decode it.

3. The Signature

To create the signature, you must take the encoded header, the encoded payload, a secret key, and the algorithm specified in the header, and sign that combination. The signature is what allows the receiving party to verify that the token was genuinely created by the issuer and that the payload has not been altered in transit.

Why Did JWTs Become the Standard?

Before JWTs, most web applications relied on session-based authentication. When a user logged in, the server created a session in its database and sent a session ID back to the browser in a cookie. Every time the user made a request, the server had to look up that session ID in the database to see who the user was.

As applications grew into distributed microservices, sharing that database lookup across dozens of servers became a massive bottleneck. JWTs solved this by being stateless. Because the user's ID and roles are embedded directly inside the token, and the token is cryptographically verified, the receiving server doesn't need to look up anything in a database. It simply verifies the math of the signature, reads the payload, and instantly grants or denies access. This allows modern architectures to scale infinitely.