Read the JWT Claim: Decoding a Token Pulled From App Storage
The challenge
You pulled this token out of a mobile app's local storage. It looks like random gibberish, but a JWT payload is not encrypted - it is just base64, which anyone can decode. In the workbench the payload is laid out for you. Read it and submit the email address it carries.
What you'll learn
- Understand that a JWT payload is base64-encoded, not encrypted
- Decode a JWT payload to read its claims with no key or cracking
- Identify and extract the email claim from a token
- Explain why secrets and PII must never be stored in a JWT payload
- Recognise tokens in client storage as readable by anyone with access
Skills tested
Prerequisites
- A JWT is three dot-separated base64url parts
- Base64 is a reversible encoding, not encryption
How it works
A JSON Web Token is three base64url segments joined by dots: header, payload, and signature. Crucially, the payload is encoded, not encrypted. Base64 is a reversible representation designed to make binary data safe to transport as text; running it backwards needs no key and no effort. So the random-looking middle segment is fully readable to anyone who holds the token.
Decode the payload here and you get {"sub":"9f2","email":"[email protected]","plan":"pro"}. The email and the plan were never hidden - they were just encoded. The signature on the end protects integrity (it stops the claims being changed without detection) but provides zero confidentiality.
This matters most on clients. A token sitting in a mobile app's local storage, in a browser, or captured on the wire can be decoded by anyone who reaches it. Treat every claim in a JWT as public. If you need to carry a real secret, encrypt it separately or keep it server-side - never assume the JWT itself hides anything.
Common mistakes
- Assuming the token is encrypted. It is base64, not ciphertext - no key is involved, so do not try to crack it.
- Trying to brute-force the signature. You do not need the signature at all to read claims; the payload decodes on its own.
- Reading the wrong claim. The answer is the
emailvalue, not thesubid or theplan. - Reformatting the answer. Submit the email exactly as it appears:
[email protected].
How to defend against it
Because every claim in a JWT is readable, design tokens to carry only non-sensitive data and protect the secrets elsewhere.
- Never put passwords, API keys, full PII, or session secrets inside a JWT payload.
- Carry only the minimum needed for authorization (an opaque user id, scopes) and look the rest up server-side.
- If a payload truly must be confidential, use an encrypted token (JWE), not a plain signed JWT.
- Store tokens carefully on clients and keep them short-lived so a leaked token has limited value.