Task 1 of 6

The Token That Says Who You Are

When you log into a modern web app, the server gives you a JWT — a small string that proves who you are. You attach it to every request after that. The server reads the token, trusts what it says, and gives you access accordingly.

The problem: JWTs are not encrypted. Anyone can read them. They are only signed — meaning the server checks the signature to verify the token was not tampered with. But if the signature uses a weak secret, you can crack it, change whatever you want inside the token, and re-sign it yourself.

A JWT HAS THREE PARTS — SEPARATED BY DOTS
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJqb2huIiwicm9sZSI6InVzZXIifQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Header Algorithm used to sign the token (e.g. HS256). Decode it and you see: {"alg":"HS256","typ":"JWT"}
Payload The claims — your username, role, expiry, anything the app stores. This is what you want to change.
Signature HMAC of header + payload using the secret. If the secret is weak, you can recreate this with a forged payload.

The payload is just Base64. Decode it, read it, change it. The only thing protecting it is the signature — and if the secret is weak, the signature is worthless.

1

A JWT payload contains {"role":"user"}. What stops you from changing it to {"role":"admin"} and sending it?

2

You decode a JWT payload and see: {"sub":"john","role":"user","iat":1700000000}. What does the role field control?

Answer 2 questions to continue