JSON Web token (JWT) is an open standard (RFC-7519) that defines a compact self-contained way for securely transmitting information between parties as a JSON object.

The format is intended for use in space constrained environments, such as HTTP authorization headers and URI query parameters.

JWTs encode claims transmitted as JSON objects contained as a payload within a single token.

The content can be verified and trusted 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.

Signed tokens can verify the integrity of the claims contained within it, while encrypted tokens hide those claims from other parties.

When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.

Why JSON?

JWTs use the JSON format because it is lightweight, widely supported, and easy to work with in web applications.

• JSON is a human-readable format, making it easy for developers to read and debug. JWT payloads often contain claims that are easy to represent in JSON.
• JSON structures are compact, minimising the size of a token when encoded. This is vital for performance, especially when tokens are transmitted in HTTP headers or URLs.
• JSON format is widely supported across multiple platforms.
• The simple key-value pair format is ideal for representing claims in a token.
• JSON data is encoded in Base64, ensuring the token is safe for transmission in URLs and HTTP headers.

Common Use cases:

The most common use case for JWTs is authorization.

Once a user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services and resources that are permitted with that token.

Single Sign On is a feature that widely uses JWTs because of its small overhead and simplicity when used across different domains. This provides a seamless user experience as users can easily consume multiple services across multiple platforms.

JWT Structure:

 in its compact form consists of three parts separated by dots – these sections are:

• Header
• Payload
• Signature

Some examples of Registered Claim Names from the ‘IANA JSON Web Token Claims’ registry are listed below. These claims are not mandatory but are instead meant to provide a starting point to help establish a useful, interoperable set of claims. They are short because a key goal of JWTs is for each representation to be compact.

‘iss’:                  –           ‘Issuer claim’ – identifies the principal that issued the JWT

‘sub’:                –           ‘Subject claim’ – identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject

‘aud’:                –           ‘Audience claim’ – identifies the recipients that the JWT is intended for. Each principal intended to process the JWT must identify itself with a value in the audience claim. If not, then the JWT must be rejected

‘exp’:                –           ‘Expiration time’ claim – identifies the expiration time on or after which the JWT must not be accepted for processing

‘nbf’:                –           ‘Not before’ claim – optional claim that identifies the time before which the JWT must not be accepted for processing

‘iat’:                  –           ‘Issued at’ claim – identifies the time at which the JWT was issued

‘jti’:                  –           ‘JWT ID’ claim – provides a unique identifier for the JWT

Auth_time: claim in a JWT token stands for authentication time. It represents the exact time when the user last authenticated. This value is expressed as a Unix time stamp (seconds since January 1, 1970).

(Note: Auth_time is an optional claim in the OpenID Connect specification).

A system may require a user to re-authenticate if the auth_time is too far in the past, even if the token is still valid.

How do JWTs work?

Once a user has successfully authenticated, a JWT will be returned.

Whenever the user wants to access a protected resource, the user agent will send the JWT, typically in the Authorization header.

The server will check for a valid JWT in the Authorization header, and if present, the user will be allowed to access the protected resources.

(Note: If JWTs are sent using HTTP headers, it is important to try to prevent them from getting too big; servers will often not allow headers > 8kb)

Benefits of JWTs:

JSON is less verbose than XML making it more compact than SAML. This makes JWT a good choice to be passed in HTML and HTTP environments.

JWTs can use a public/private key pair in the form of an X509 certificate for signing making them easy and secure to use. This avoids the need for any pre-shared keys and allows protected endpoints to verify a token on their own without requiring checks against an Authentication Server.

JSON parsers are also common in most programming languages because they map directly to objects. This makes it easier to work with JWT than, for example, SAML assertions.

---

In summary, the combined operating efficiency, enhanced security and interoperability across multiple platforms (especially mobile) means JWTs have become the de-facto standard for identity assurance.

---