Read the JWT Claim: Decoding a Token Pulled From App Storage
Le défi
Vous avez extrait ce jeton du stockage local d'une application mobile. Cela ressemble à du charabia aléatoire, mais la charge utile d'un JWT n'est pas chiffrée - c'est juste du base64, que n'importe qui peut décoder. Dans l'atelier, la charge utile est présentée pour vous. Lisez-la et soumettez l'adresse e-mail qu'elle contient.
Ce que tu vas apprendre
- 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
Compétences testées
Prérequis
- A JWT is three dot-separated base64url parts
- Base64 is a reversible encoding, not encryption
Comment ça marche
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.
Erreurs fréquentes
- 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].
Comment s'en protéger
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.