Introduction to JWTs

---

Understanding the basics of JWTs, including how they work, their structure, and how web applications use them, is paramount before learning how to perform attacks and exploit vulnerabilities associated with them.

---

What is a JSON Web Token (JWT)?

JWTs is a way of formatting data (or claims) for transfer between multiple parties. A JWT can either utilize JSON Web Signature (JWS) or JSON Web Encryption (JWE) for protection of the data contained within the JWT, though in practice, JWS is much more commonly used in web applications. Thus, we will solely discuss JWTs that utilize JWS in this module. Two additional standards comprise JWTs. These are JSON Web Key (JWK) and JSON Web Algorithm (JWA). While JWK defines a JSON data structure for cryptographic keys, JWA defines cryptographic algorithms for JWTs.

A JWT is made up of three parts, which are separated by dots:

• JWT Header

• JWT Payload

• JWT Signature

Each part is a base64-encoded JSON object:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJIVEItQWNhZGVteSIsInVzZXIiOiJhZG1pbiIsImlzQWRtaW4iOnRydWV9.Chnhj-ATkcOfjtn8GCHYvpNE-9dmlhKTCUwl6pxTZEA

We will now look at these parts and discuss their function within the JWT.

---

Header

The first part of the JWT is its header. It comprises metadata about the token itself, holding information that allows interpreting it. For instance, let us look at the header of our example token from before. After base64-decoding the first part, we are left with the following JSON object:

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

As we can see, the header only consists of two parameters in this case. The typ parameter is usually set to "JWT", and the alg parameter specifies the cryptographic signature or MAC algorithm the token is secured with. Valid values for this parameter are defined in the JWA standard:

"alg" Parameter Value	Signature/MAC Algorithm
HS256	HMAC using SHA-256
HS384	HMAC using SHA-384
HS512	HMAC using SHA-512
RS256	RSASSA-PKCS1-v1_5 using SHA-256
RS384	RSASSA-PKCS1-v1_5 using SHA-384
RS512	RSASSA-PKCS1-v1_5 using SHA-512
ES256	ECDSA using P-256 and SHA-256
ES384	ECDSA using P-384 and SHA-384
ES512	ECDSA using P-512 and SHA-512
PS256	RSASSA-PSS using SHA-256 and MGF1 with SHA-256
PS384	RSASSA-PSS using SHA-384 and MGF1 with SHA-384
PS512	RSASSA-PSS using SHA-512 and MGF1 with SHA-512
none	No digital signature or MAC performed

Our example token is secured with HMAC using SHA-256 in this case. There are additional parameters that can be defined in the JWT header as defined in the JWS standard, some of which we will take a look at in the upcoming sections.

---

Payload

The JWT payload is the middle part and contains the actual data making up the token. This data comprises multiple claims. Base64-decoding the sample JWT's payload reveals the following JSON data:

{
  "iss": "HTB-Academy",
  "user": "admin",
  "isAdmin": true
}

While registered claims are defined in the JWT standard, a JWT payload can contain arbitrary, user-defined claims. In our example case, the iss claim is a registered claim that specifies the identity of the JWT's issuer. The claims user and isAdmin are not registered and indicate that this particular JWT was issued for the user admin, who seems to be an administrator.

---

Signature

The last part of the JWT is its signature, which is computed based on the JWT's header, payload, and a secret signing key, using the algorithm specified in the header. Therefore, the integrity of the JWT token is protected by the signature. If any data within the header, payload, or signature itself is manipulated, the signature will no longer match the token, thus enabling the detection of manipulation. Thus, knowledge of the secret signing key is required to compute a valid signature for a JWT.

---

JWT-based Authentication

Now that we know the basics about JWTs let us discuss a typical use case for them: JWT-based authentication.

Stateful Authentication

Traditionally, the user presents a session token to the web application, which then proceeds to look up the user's associated data in some kind of database. Since the web application needs to keep track of the state, i.e., the data associated with the session, this approach is called stateful authentication.

Stateless Authentication

On the other hand, in JWT-based authentication, the session token is replaced by a JWT containing user information. After verifying the token's signature, the server can retrieve all user information from the JWT's claims sent by the user. Because the server does not need to keep a state, this approach is called stateless authentication. Remember that the JWT's signature prevents an attacker from manipulating the data within it, and any manipulation would result in a failed signature verification.