Web Security: Understanding JWT

JWT: JSON Web Token

JWT is a standard for safely passing claims, pieces of information or assertions made about a subject, in a space-constrained environment.

Its key features are compactness, simplicity, and usability.

A JWT often looks like gibberish, but it is a very compact representation of claims, together with a signature to verify its authenticity.

Here's an encoded JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30

And here's what it decodes to:

Header:

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}

Claims are also known as assertions made about a certain party or object.

Some claims and their meaning are defined as part of the JWT specification, known as Registered claims, while others are user-defined.

Registered claims, e.g., iss (issuer), sub (subject), aud (audience), exp (expiration time), iat (issued at), and jti (JWT ID) have standardized meanings under RFC 7519, so any system that reads a JWT knows what to expect from them.

Everything else is up to the issuer, e.g., name, email, are user-defined, and their meaning is entirely dependent on what the application decides to put there.

---

Why JWT? What does it solve?

JWTs are primarily designed to securely transfer claims between two parties in a simple, optionally validated, and/or encrypted container format.

There are other ways of asserting claims, such as SAML, which is based on XML, PASETO (Platform-Agnostic SEcurity TOkens), Branca.

PASETO and Branca were created as a response to JWT design flaws; however, JWT still has the highest adoption rate, similar to the REST/GraphQL adoption battle.

Another great use case for JWT is client-side (stateless) sessions.

Stateless means a server does not keep session records in a database (the traditional method).

Once a session starts, the server bundles the session data, such as userId, roles, and whatever information would previously be stored in the session database row, into a JWT, signs it, and that token is used for session continuity on the client side.

The server has lost its source of truth, simply because the session token now lives on the client side, and it cannot blindly trust what the client sends back. This is why we have JSON Web Signature (JWS), which allows the server to verify that the data in the JWT has not been altered.

While tampering is one concern, privacy is another; some payloads often contain sensitive data.

If a payload contains sensitive data, JSON Web Encryption (JWE) solves this by encrypting the data, which deters the client and/or anyone intercepting the token from reading its content.

Most session records only need signing; encryption is only done when certain claims should not be visible.

Other Practical Applications

JWT shows up in a handful of recurring patterns across the industry. Here are the most common ones.

• Authentication & Authorization: the most familiar use case. A signed JWT (an access token) is sent with each request, typically as Authorization: Bearer <token>. This allows the server to verify identity and permissions without a database lookup on every call.

• Access & Refresh Tokens: in OAuth 2.0-based systems, JWTs are commonly used as access tokens: short-lived, often carrying an expiration and scope, used to prove the client is allowed to access a given resource.

When an access token expires, a longer-lived refresh token is used to request a new one without ending the session and forcing the user to log in again.

• Federated Identity, SSO & OpenID Connect: JWT is the token format of choice in OAuth 2.0/OIDC-based federated identity systems, where one IdP authenticates a user on behalf of multiple, unrelated services.

OIDC in particular defines the ID token: a JWT containing the authenticated user's profile information. I covered the full OAuth 2.0 and OIDC flow, including PKCE, in a previous article, worth a read if you want the deep dive.

• Microservices communication: In a distributed system, JWTs let one service pass verified identity and claims to another without a shared session store, which keeps services decoupled and independently scalable.

• Resource-constrained environments (IoT): CWT applies the same signed-claims model as JWT but with a binary, more compact encoding, better suited to low-power devices with limited bandwidth.

---

💡Pro Tip

JWT is an open standard for representing information, called claims, as a concise JSON object. CWT (CBOR Web Token) serves the same purpose but uses Concise Binary Object Representation (CBOR) instead of JSON, making it better suited for low-power, resource-constrained IoT transmissions.

Thanks for reading, catch you in the next one.