JSON Web Tokens

A JSON Web Token often referred to as JWT is an open standard for transferring data securely between two parties in a JSON payload that can be verified and trusted by means of a digital signature. In simpler terms, a JWT is just a string that is sent in an HTTP request from the client to the server to validate the authenticity of the client.

Structure

A JWT is composed of three distinct components separated by dots.

Header.Payload.Signature

Header

The header typically consists of two parts: the type of the token, which is JWT, and the hashing algorithm being used to create the JWT signature component, such as HMAC SHA256 or RSA. For e.g.

{
 “alg”: “HS256”,
 “typ”: “JWT”
}

This JSON is then Base64Url encoded to form the first part of the JWT. i.e

header: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Payload

The payload is any data that we want to include in the JWT. It is also referred to as claims because when a client sends a JWT in a request, they are claiming that this information belongs to them. If this data has tampered, JWT will be invalid. One thing we need to be careful about the payload is that it is readable by anyone. So we should avoid putting secret information here unless they are encrypted. A typical example of the payload is

{
  “user_id”: “12345”,
  “admin”: true,
  “expiry_at”: “Mon Jun 17 2019 11:12:13 GMT+0530”
}

This JSON is also then Base64Url encoded to form the second part of the JWT. i.e

payload: eyJ1c2VyX2lkIjoiMTIzNDUiLCJhZG1pbiI6InRydWUiLCJleHBpcnlfYXQiOiJNb24gSnVuIDE3IDIwMTkgMTE6MTI6MTMgR01UKzA1MzAifQ

Generally, we can add as many fields as we would like in the payload but it is recommended to keep it as small as possible because having larger JWT could negatively affect the performance and introduce latency.

Signature

As I mentioned earlier that the idea of using JWT is to verify the authenticity of the source of the data, in order to do so, the algorithm specified in the header is used to sign the base64URL encoded header and payload using a secret key. We are using HS256 algorithm for this example so generating signature would look something like this.

HMACSHA256(
     base64UrlEncode(header) + "." + base64UrlEncode(payload),
     "secretKey"
)

The value generated from it will be again Base64Url encoded to form the third part of the JWT. ie.

signature: G7Wj5dGTnd5s2mbKQafSLLqV6Jqj4uMXkts3GqTViOo

Now if we combined all these 3 components ie. header, payload and signature we have a JWT token which looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiMTIzNDUiLCJhZG1pbiI6InRydWUiLCJleHBpcnlfYXQiOiJNb24gSnVuIDE3IDIwMTkgMTE6MTI6MTMgR01UKzA1MzAifQ.G7Wj5dGTnd5s2mbKQafSLLqV6Jqj4uMXkts3GqTViOo

Let’s try to visualize how this JWT can be used to validate the authenticity of the information passed in the resource server.

JWT based authentication

Here, we have three entities: client, authentication server and resource server. The user or client will provide their credentials to the authentication server and if the user is authenticated, it will create a JWT using the above-mentioned structure and return it to the user. Now when the user makes any request to resource server using this JWT token with authorization header, it will generate the signature using the same algorithm and verify it against the one included in the JWT token. If the signature matches, then it indicates that the data was originated from an authentic source. Otherwise, it would mean that it has been tampered midway thus helping us in the identification of sniffing of data.

One thing we need to understand though is the objective of JWT tokens is not to hide the data but to verify the authenticity of the source of the data. The payload data is encoded and signed but not encrypted, so we should not include sensitive information in the payload of JWT unless they are encrypted.

This summarizes the simple idea of JWT token implementation in web applications. It is simple, easy and helps in adding one extra layer of trust and security in our application.