Authentication using JSON Web Tokens.
Tags: webdev, node, security, beginners
Published: 2024-04-11 22:24:59

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z21sdr3ja3q09i20q3w6.gif)

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
1. "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.
2. "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.
3. "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](https://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.