document.body.classList.toggle('menu-open', show); // Add 'menu-open' class to body.

JWT Security Part 2: Implementation and basic concepts – decoding the mystery

Jan Masters
Written by Jan Masters
November 21, 2024
Tags – ,

Welcome back, security enthusiasts and JWT curious!

In our last post, we teased you with the promise of unravelling the mysteries of JSON Web Tokens. This week, we’re going to talk about implementation and basic concepts.

What's in a JWT?

First things first: what exactly is a JWT? No, it’s not a sandwich…although it does have three parts!

It’s actually a compact, URL-safe means of representing claims to be transferred between two parties. It’s like a digital passport, containing information about the user and signed by the issuer.

JWTs consists of three parts:

  1. Header
  2. Payload
  3. Signature

 

These parts are separated by dots, resulting in something that looks like this:


Credit: http://jwt.io/
Let’s break it down, shall we?

The JWT's business card

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

“`json
{
“alg”: “HS256”,
“typ”: “JWT”
}
“`

This JSON is then Base64Url encoded to form the first part of the JWT.

Payload: where the magic happens

The payload contains the claims, i.e. statements about the user and any additional metadata. There are three types of claims: registered, public, and private.

“`json
{
“sub”: “1234567890”,
“name”: “John Doe”,
“admin”: true
}
“`

This JSON is also Base64Url encoded to form the second part of the JWT.

Signature: the security guard

The signature is used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn’t changed along the way. It’s created by taking the encoded header, the encoded payload, a secret, and the algorithm specified in the header, and signing that.

“`
HMACSHA256(
base64UrlEncode(header) + “.” +
base64UrlEncode(payload),
secret)
“`

The life of a JWT

Now that we know what’s inside, let’s look at how it’s typically used:

  1. User logs in: They send their credentials to the server.
  2. Server creates a JWT: If the credentials are valid, the server creates a JWT and sends it back to the user.
  3. User stores the JWT: Usually in local storage (not so secure option) or a cookie (secure option).
  4. User sends the JWT with each request: Typically in the Authorisation header.
  5. Server verifies the JWT: If it’s valid, the server processes the request.

 

It’s like a VIP pass at a fancy club. You show your credentials at the door, get a wristband (the JWT), and then use that wristband to access different areas of the club.


Credit: http://jwt.io/

The good, the bad, and the JWT

JWTs have some great benefits:

  • Stateless: The server doesn’t need to keep track of sessions.
  • Portable: They can be used across different domains.
  • Efficient: They’re compact and can be sent through URLs, POST parameters, or inside HTTP headers.

But they’re not without their pitfalls:

  • Can’t be revoked easily: Once issued, a JWT is valid until it expires, unless additional systems have been implemented. If those systems don’t exist then your only option is to reset your secret key, which will invalidate every single JWT.
  • Potential for large tokens: If you stuff too much into the payload, your tokens can get bloated.
  • Security depends on the implementation: A poorly-implemented system can be a security nightmare.

In conclusion

And there you have it! You’re now equipped with the basic knowledge of what JWTs are and how they work. You’re practically a JWT whisperer at this point.

But don’t get too comfortable just yet. In our next post, we’ll be diving into the murky waters of secret key management in JWT. Trust me, it’s more exciting than it sounds, and it might just save your application from turning into a hacker’s playground.

Until then, keep your tokens secure and your secrets secret!

Like what you see? Share with a friend!

Jan Masters

This article is written by

Jan Masters

Cyber Security Engineer

In cyber security, there are no magic spells – just knowledge, experience, luck, and a touch of wizardry to turn challenges into solutions.

Cyber Security Engineer Jan – our resident Cyber Wizard (@FlyingPhishy on X, if you’re asking) – is a jack-of-all-trades consultant specialising in infrastructure, cloud, and R&D. He delivers high-quality, holistic penetration tests and drives innovation from within, ensuring our penetration testing services are modern and break the mould.