Read the JWT Claim: Decoding a Token Pulled From App Storage
O desafio
Você tirou este token do armazenamento local de um app móvel. Parece um amontoado aleatório, mas o payload de um JWT não é criptografado - é apenas base64, que qualquer um pode decodificar. Na bancada, o payload está disposto para você. Leia-o e envie o endereço de e-mail que ele carrega.
O que você vai aprender
- 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
Habilidades testadas
Pré-requisitos
- A JWT is three dot-separated base64url parts
- Base64 is a reversible encoding, not encryption
Como funciona
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.
Erros comuns
- 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].
Como se proteger
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.