paint-brush
JWT Explained in 4 Minutes, With Visualsby@jaypmedia
315 reads
315 reads

JWT Explained in 4 Minutes, With Visuals

by Jean-Paul RustomFebruary 28th, 2024
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Explore JWT authentication: a secure, stateless user authentication standard for web apps. Learn its structure, workflow, pros, and cons.
featured image - JWT Explained in 4 Minutes, With Visuals
Jean-Paul Rustom HackerNoon profile picture

Introduction

JWT authentication and session authentication are ways to authenticate users of your web app. In this article, we will explain the details of JWT, its structure, and its pros and cons. JWT stands for JSON Web Token, and it is a commonly used stateless user authentication standard used to securely transmit information between client and server in a JSON format.


A JWT is encoded and not encrypted by default. It is digitally signed using a secret key known only to the server. It can be encrypted, but for this article, we will focus on signed, non-encrypted tokens.

Structure of JWT

A JSON Web Token consists of 3 parts separated by a period. The header, the payload, and the signature. Each section is base64 encoded.

JWT encoded structure

Header

The header consists of a token type, which is JWT, and the signing algorithm used, such as HMAC SHA256 or RSA.

{ 
  "typ": "JWT",    
  "alg": "HS256"
}

Payload

The payload consists of the claims. Claims are statements about the user and additional data. For example, we have the time the token was issued. We also have its expiration time because tokens should expire.

{
"iss": "example_issuer",
"sub": "user_id123",
"exp": 1644768000,
"iat": 1644744000
}

Signature

The signature is the most important part of a JWT. It is calculated using the header, the payload, and the secret, which are fed to the signing algorithm to use.

signature = HMAC-SHA256(base64urlEncode(header) + "." + base64urlEncode(payload), secret_salt )

JWT Structure Decoded

Steps

The steps involved in a typical JWT authorization flow are as follows:

1- Authentication: The user signs in using a username and password or using, for example, Google or Facebook. The server verifies the provided credentials.

2- Token Generation & sending token to client: The server will generate the JWT and send it to the client, which stores it for future use.

3-Sending the Token to server: When the client wants to access a protected resource on the server, it sends the JWT in the Authorization header of the HTTP request.

axios.get(URL, {
    headers: {
        'Authorization': 'Bearer ' + token,
    },
})

4-Verifying the Token: The server receives the request and verifies the JWT by checking its signature using the secret key that was used to sign it. If the JWT is valid, the server extracts the information contained in it and uses it to determine what actions the user is authorized to perform.

5- Authorizing the Request: If the user is authorized to access the resource, the server returns the requested data. If the user is not authorized, the server returns an error message.

JWT Flow

Advantages

JWT Advantages

  • Lightweight
  • Portable: It can be processed on multiple platforms, including web and mobile.
  • JSON parsers are common in most programming languages.
  • Protected against tampering because of the secret key stored on the server side.
  • The server does not need to store any session information because of the stateless nature of the JWT token.

Disadvantages

Disadvantages

  • On the server side, you should manually mark non-expired JWT as invalid on logout. A JWT can still be valid even after it has been deleted from the client.

JWT still valid

A method used is token blacklisting, which involves maintaining a list of invalidated tokens on the server side, preventing their reuse for authentication.

Token blacklisting

  • For signed, nonencrypted tokens, we should not store sensitive info because JWT is protected against tampering but can be decoded and read by anyone.
  • Can provide full access if intercepted. That’s why JWTs on the client side should be stored somewhere secure, for example, in the browser in an HttpOnly cookie.