JWT (JSON Web Token)
This document analyzes JWT (JSON Web Token).
1. JWT (JSON Web Token)
![[Figure 1] JWT](/blog-software/docs/theory-analysis/jwt/images/jwt.png)
[Figure 1] JWT
JWT, as the name suggests, refers to a JSON-based Web Token. [Figure 1] shows the structure of JWT and the process of creating JWT. JWT consists of three parts: Header, Payload, and Signature, and each part is connected through “.” (period). Header and Payload are configured in JSON-based Key-value format, and Signature is generated based on Header and Payload.
1.1. Header
The Header contains the “typ” Key that indicates the Type and the “alg” Key that indicates the Algorithm. Type refers to the type of Token, and JWT has “JWT” as a fixed string value. Algorithm refers to the encryption Algorithm used when generating Signature based on Header and Payload. The content of the Header is encoded in Base64 and stored in JWT.
1.2. Payload
The Payload stores the Meta Data of the Token and the actual Data that the Token wants to deliver in Key-value format. The Key-value of Payload is called Claim, and Claims are divided into Reserved Claims and Custom Claims. Custom Claims are further divided into Public Claims and Private Claims. Reserved Claims store Meta information of the Token. Names of Reserved Claims include “iss” which means the issuer of the Token, “sub” which indicates the name of the Token, “iat” which indicates the issuance time of the Token, etc.
Custom Claims store the actual Data that the Token wants to deliver. The names of Public Claims are open to everyone, and the names of each Public Claim generally represent Data that is commonly transmitted. In other words, Public Claims generally store Data that is commonly transmitted. Names of Public Claims include “name” which means Full Name, “email” which means Email address, etc. The names of Private Claims use names determined by agreement between Apps that exchange Tokens. The “app” Key in [Figure 1] represents the Key of a Private Claim.
The names of Reserved Claims and Public Claims can be checked at this link. The content of Payload is also encoded in Base64 like Header and stored in JWT.
1.3. Signature
Since JWT’s Header and Payload are encoded in Base64, anyone can decode and check JWT’s Header and Payload, and it is not difficult to intercept JWT and replace the existing Payload with a manipulated Payload. JWT uses Signature to solve these security problems. Through Signature, it can be verified that Header and Payload have not been manipulated and that they were transmitted from an authenticated App.
Signature is generated by encrypting the string that connects Base64-encoded Header and Payload with “.” (period) and a Password (symmetric key, asymmetric key) arbitrarily set by the user, and then encoding it again in Base64. The App that receives JWT generates Signature using the Header, Payload of the received JWT, and the Password it knows, and then compares it with the Signature of the received JWT. If the two Signatures are the same, it means that the JWT is valid.
If the Payload has been changed or an App that does not know the Password (unverified) generates Signature using a wrong Password and includes it in JWT, the Signature of JWT and the Signature generated by the App that received JWT will inevitably be different. In this way, JWT can verify that it is valid by itself without external help.
JWT can use various encryption Algorithms for Signature generation. Generally, HMACSHA256 Algorithm is often used when symmetric key-based encryption is needed, and RSA256 Algorithm is used when asymmetric key (public key, private key) based encryption is needed. [Figure 1] shows the process of encryption using HMACSHA256 Algorithm.
1.4. Characteristics and Uses
JWT can store desired Data in Payload and verify its integrity using Signature. The characteristic of containing all necessary information like JWT is called Self-contained. JWT’s Self-contained characteristic makes it advantageous to use JWT in Stateless Apps like REST API Servers.
The biggest advantage of Stateless Apps is free Scale Out. If Stateless Apps use Tokens that do not have Self-contained characteristics, that is, Tokens that require the help of external Token Servers to understand the meaning and verify the validity of Tokens, the load on external Token Servers also increases every time Stateless Apps Scale Out. This increase in load on external Token Servers becomes an element that hinders Scale Out of Stateless Apps. Since Apps that receive JWT can perform meaning understanding and validity verification of received JWT by themselves, these load problems do not occur.
JWT is mainly used as a Token for authentication/authorization of Services by putting authorization information in Payload based on Self-contained characteristics, or for the purpose of exchanging Data encrypted in Web environments.