Why did the JSON Web Token need a break?
Because it had too many “claims” to make!

A JWT (JSON Web Token) is simply a base64url encoded string which is short and efficient enough to transport over the internet. This string looks something like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIyMjExMyIsIm5hbWUiOiJyb2JpbidzIGNsaWVudCIsImlhdCI6MTUxNjIzOTAyMn0.pmV2EoDtuoSn1tn9yV0FDrV2x-W_ixcEVAb4Zkjdqms

Lol, doesn't look like it makes much sense, does it? As you can see the string is split into 3 parts all concatenated with a period ‘.’

These parts are respectively the:

• Header
• Payload and the
• Signature

It is important to know what a JWT should contain as we now go into the flow of authenticating users using JWTs.

Flow

The flow of using JWTs to authenticate users typically divided into two processes.

1. Creating the JWT
2. Verifying the JWT.

Creating/Signing the JWT

Let’s assume we have a robot named Robin. Robin’s job is to create JWTs.

To do this, Robin first requires some things from us, she needs:

• A Header JSON. This JSON should typically contain two name-value pairs. The first is the alg (short for algorithm) property which has a value specifying the type of algorithm needed to sign and verify the JWT and the second is the typ (short for type) which has a value specifying the type of token it is.
• A Payload JSON. This payload should also contain name-value pairs which are called ‘claims. A claim is a statement about an entity (usually the user) that includes information like their identity, role, or permissions. Claims can be used to convey a variety of data, such as user information, permission data, and other metadata. Claims can be anything you want to store about a client. There are already predefined claims though that help to provide consistency across different JWT implementations, known as Registered Claims. Some examples are
• “iss” (issuer): This claim identifies the entity that issued the JWT. The value of this claim should be a string that identifies the issuer, such as a URL or a unique identifier.
• “sub” (subject): This claim identifies the subject of the JWT. The value of this claim should be a string that identifies the user or entity that the JWT represents.
• “exp” (expiration time): This claim specifies the expiration time of the JWT.

Naturally, we store a client’s id in the sub claim.

• TOP SECRET key(s). The last thing Robin needs from us, (depending on the value of the alg property in the header JSON) is a key/set of keys needed to Sign the JWT. By Signing a JWT we are basically taking the Header and Payload data and hashing them with a secret key or pair of keys using the algorithm specified in alg property

AND THAT’S IT. Robin will take these and create a JWT. So Robin does the following:

1. Accepts the Header and Payload JSON provided.
2. Encodes each JSON into a base64url string.
3. Concatenates them with a period ‘.’
4. Hashes the result of the concatenation using the algorithm specified Header and TOP SECRET key(s) provided.
5. Returns the JWT in the form base64urlencoded(header).base64urlencoded(payload).base64urlencoded(hash_result_of_step_3)

NOTE: Never store sensitive information about a client in the payload as the JWT is just encoded and not encrypted. You can paste the JWT I gave as an example above in this cool site which basically allows you to see in decoded. JSON Web Tokens – jwt.io

Some packages like the NPM jsonwebtoken package help by abstracting the creation of JWTs.

This process of creating) a JWT should occurs when a client has successfully logged into your system (this could be through a username and password implementation).

Verifying the JWT

Verifying a JWT is actually pretty straight forward. Naturally, when a client sends a request to a protected route, they attach the JWT to the request, it’s mostly in the Authorization header. The following steps then take place to verify the JWT.

• Splitting the JWT string concatenated by periods '.' to extract each component. (the header, payload and signature)
• Using an algorithm (specified by the algorithm in header) and the secret key/public key to compare the resulting hash to the signature of the JWT. If they match, then we know the JWT has not been tampered with.
• If the results of the hashes do not match, or the JWT has expired (info at expiry time gotten from payload), the JWT gets rejected.

Reasons why JWTs are used.

A simple google search will show you a lot of reasons why JWTs are used but a couple stood out to me:

1. Stateless: JWT tokens are stateless, meaning that the server does not need to keep track of the user's session. The server does not need to have a database where it stores sessions.
2. Scalability: JWT tokens can be used across multiple servers for authentication. In a microservices architecture where a client needs to visit multiple servers, each server does not need a session store, it just needs to verify the client’s JWT.