The Basics of JSON Web Token (JWT)

Before I explain what it is, I’ll need to discuss a few things first. Let’s first discuss why they’re used. HTTP is stateless meaning that information stored in one request cannot be transferred through to another request. Why does this matter? Imagine you’re a user for XYZ website. Each time you go to another page, your browser is making a request. Without any information stored, you’d have to log in every time you go to another page. Solutions were created in order to address this, one of which is sessions and another being JWT.

Let’s talk about the more traditional solution first, sessions. You’ve probably heard of session and cookies before. A session is an object that’s assigned to a user on the server side. A cookie is a hash that’s stored on the client-side (browser). Let’s say you’re logging into XYZ website. A session is created by the server and you are assigned a session ID on the server side. A cookie is also created and returned to the browser with an ID and that is compared to session id. This way, each time a new request is made (or you going to another page), the server checks to make sure the ID on the cookie matches with the session ID created for the user. This makes sure you don’t have to keep logging in between requests.

Now you may be asking yourself, if we have sessions and cookies, what’s the point of JWT? Both sessions and JWT work similarly in the beginning but after a user logs in successfully, instead of storing information on the server, the server creates a JSON Web Token and sends it back to be stored on the client side along with a signature. Think of JWT as a means of maintaining “sessions” on the client side (browser) rather than the server. Similar to sessions, each time you make a new request, the JWT signature is checked and if all is well, you don’t have to keep logging in.

So how does JWT work? Take a moment to look at the image below as I’ll explain it and ask that you cross reference the image.

Image from

The left side labeled Encoded refers to what is sent to the client and from the client. The right side labeled Decoded is the decoded version of the left side. As you’ve already noticed, there’s three different parts of the decoded side, all separated by periods when encoded. Let’s break down each part and what they contain.

· Header

1. Alg — refers to the algorithm used to encode/decode the information on the token

2. Typ — refers to the type of token used

· Payload

  1. Sub — refers to the ID of the user
  2. Name — Arbitrary information for the user such as username, etc
  3. Iat — stands for issued at, useful for if you want tokens to expire at a certain time

· Verify Signature

  1. A combination of the header, payload, and secret key that’s all been encoded for security reasons. This is for security reasons to make sure the digital signature assigned has not been tampered with.

Let’s now discuss situations in where you would want to use JWT.

For example, let’s say XYZ Inc. is a video game company and they have separate servers to host accounts between their video games. Let’s say XYZ Inc. wanted it so if you logged into Video Game A and decided to switch to Video Game B, you wouldn’t have to log in again (in order to make a more seamless experience). If you used sessions for this case, the issue is that Video Game A and Video Game B have their own separate servers and if you logged into Video Game A and received a session id from there, it wouldn’t be found in Video Game B. Thus, you’d have to log into Video Game B. If you were use JWT, each server could share the same secret key and you’d just have to share the same token to switch between servers.

Now you may be thinking to yourself, JWT are better than sessions and in some cases, they are! However, they’re not good enough to be a total replacement of sessions. JWT have their own set of issues. Some of which include, storing and transporting the token securely.

In summation, JSON Web Tokens are another great way of providing authorization requests to a user in between said requests. One thing that helps me remember is to think of JSON Web Tokens as a way of maintaining sessions on the client side. JSON Web Tokens aren’t necessarily better than sessions but they do have their benefits.

Flatiron School Alumni & Software Engineer