Introduction

JWT Concepts

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. It’s one of the most popular ways of authentication. It’s an encoded string that can contain any amount of data and it is cryptographically signed (by the server side). No middleman can modify it.

NOTE: It’s always best practice to use HTTPS with JWT.

The JWT token consists of 3 parts:

1. Header
2. Payload
3. Signature

Header

It contains information about the alogirthm used to generate the signature. These could be HMAC, SHA256 or RSA. It is Base64 encoded to form the first part of the JWT.

The header can also hold an additional information like “kid” [key id]. This is particularly useful when there are multiple keys used to sign different kinds of tokens within your application and have to look up the right one to verify the signature.

Payload

This is the second part of the token. It contains claims, which are statements/fields about an entity and any additional data. In JWT, there are 3 main types of claims — registered, public and private.

The most widely used claims are iss, exp and sub.

iss — issuer is used to identify the issuer of the the JWT.

exp — expiration time of the JWT

sub — subject identifies the principal

This payload is also Base64 encoded.

Signature

This is created from the encoded header, encoded payload, algorithm in the header and a secret key.

The final output is 3 base64 URL strings separated by dots that can be sent in HTTP requests.

Benefits

There are benefits to using JWTs when compared to simple web tokens (SWTs) and Security Assertion Markup Language (SAML) tokens.

• More compact: JSON is less verbose than XML, so when it is encoded, a JWT is smaller than a SAML token. This makes JWT a good choice to be passed in HTML and HTTP environments.
• More secure: JWTs can use a public/private key pair in the form of an X.509 certificate for signing. A JWT can also be symmetrically signed by a shared secret using the HMAC algorithm. And while SAML tokens can use public/private key pairs like JWT, signing XML with XML Digital Signature without introducing obscure security holes is very difficult when compared to the simplicity of signing JSON. Read more about JWT signing algorithms in our blog.
• More common: JSON parsers are common in most programming languages because they map directly to objects. Conversely, XML doesn’t have a natural document-to-object mapping. This makes it easier to work with JWT than SAML assertions.
• Easier to process: JWT is used at internet scale. This means that it is easier to process on user’s devices, especially mobile.

JWTs can be used in various ways:

• Authentication: When a user successfully logs in using their credentials, an ID token is returned. According to the OpenID Connect (OIDC) specs, an ID token is always a JWT.
• Authorization: Once a user is successfully logged in, an application may request to access routes, services, or resources (e.g., APIs) on behalf of that user. To do so, in every request, it must pass an Access Token, which may be in the form of a JWT. Single Sign-on (SSO) widely uses JWT because of the small overhead of the format, and its ability to easily be used across different domains.
• Information Exchange: JWTs are a good way of securely transmitting information between parties because they can be signed, which means you can be sure that the senders are who they say they are. Additionally, the structure of a JWT allows you to verify that the content hasn’t been tampered with.