JSON Web Tokens(JWT)

What is actually JWT and how it can securely transmit information?

JWT which stands for JSON Web Tokens is one of the most popular authorization ways used in most web applications today.

In this article, we gonna discuss how the JWT can be used in web apps especially in the context of securing web applications.

We do have some other authorization strategies like Session Tokens etc..but in this article, we mainly focus only on JWT.

What do JWTs look like?

Since JWT is basically used for managing authorization the main idea behind that is to create a standard way to communicate with two parties securely.

Because of its relatively small size, a JWT can be sent through a URL, through a POST parameter, or inside an HTTP header, and it is transmitted quickly. A JWT contains all the required information about an entity to avoid querying a database more than once. The recipient of a JWT also does not need to call a server to validate the token.

When to use JWTs

JWTs can be used in various ways.

1. Authorization

Once the user/client successfully authenticates for the system by using a username or password, each subsequent request must pass the JWT which will allow the user to access routes, services, or resources (e.g., APIs).

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

2. 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.

How actually JWT Works in the real world?

JWT work Flow in real world

Let’s imagine a user authenticates instead of the server saving that user information in a state on the server and returning the ID as a token, it returns the user information as a token(JSON Object). Imagine a JSON payload being returned with the user information back. That JSON object can be saved in the local storage or cookies. It’s totally up to you to decide.

Every time the client makes a subsequent request to the server, the client will send the whole JSON Token with the request. Then the server will look for that JSON Token and verify that the user is successfully authenticated.

The problem of security is handled here by signing the tokens that are handed across each time. When a user authenticates, the server doesn’t send any JSON Object it sends something in a special signed format with a signature.

So, whenever the user sends a subsequent request, the SIGNED JWT is sent back to the server and the server will verify the signature and it trusted only if it is valid.

Whenever the user wants to access a protected route or resource, the user agent should send the JWT, typically in the Authorization header using the Bearer schema. The content of the header should look like the following:

Authorization: Bearer <token>

What is the JWT structure?

Sample JSON Web Token (Figure 1)

If you carefully look at the above Sample JWT, you can see 3 different parts in 3 different colors, separated by dots (.)

That's because JSON Web Tokens consist of three parts separated by dots (.), which are:

  • Header
  • Payload
  • Signature

Header

The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.

Sample — Header (Bas64 Decoded) (Figure 2)

Then, this JSON is Base64Url encoded to form the first part of the JWT. (Red color part is the header)

Payload

The second part of the token is the payload, which contains the claims. Claims are statements about an entity. There are three types of claims

  • Registered claims: These are a set of predefined claims which are not mandatory but recommended, to provide a set of useful, interoperable claims.
  • Public claims: These can be defined at will by those using JWTs. But to avoid collisions they should be defined
  • Private claims: These are the custom claims created to share information between parties that agree on using them and are neither registered or public claims.
Sample — Payload (Bas64 Decoded) (Figure 3)

The payload is then Base64Url encoded to form the second part of the JSON Web Token. (Pink color part in the Sample JWT Token)

Signature

Signature is the most important part of this token and it is the only part that is hidden from the public. Because to generate this signature server will user security key and that key will only know by the server.

To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.

For example, if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way:

Sample — Signature (Figure 4)

The signature is used to verify the message wasn’t changed along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is.

Then, you have to put it all together. Figure 1. shows a JWT that has the above-mentioned header (Figure 2) and payload encoded (Figure 3), and it is signed with a secret (Figure 4).

JWT = Encoded Header + Encoded Payload + Secret Key

If you want to play with JWT and put these concepts into practice, you can use jwt.io.

Hope this helps and let me know what you think in the comment section below.

Thank you.

A Computer Science enthusiast. Software Engineer. Full Stack developer. Music Lover