JSON Web Tokens (JWTs) carry signed claims between APIs, SPAs, and mobile apps. They look opaque in Base64, but decoding is easy — the security is in signature verification, not secrecy. This guide explains JWT structure, safe inspection practices, and how to debug tokens with ToolSphare's JWT Decoder without leaking secrets.
Ключевые выводы
- A JWT has three parts: header, payload, and signature — dot-separated Base64URL strings.
- Decoding is not decrypting; anyone can read the payload unless additional encryption is used.
- Never paste production tokens with live secrets into untrusted websites or chat logs.
- Always verify signatures server-side with the correct algorithm and key — never trust client-side decode alone.
- Use exp, iat, aud, and iss claims correctly to prevent replay and cross-service token misuse.
JWT structure in plain language
A JWT looks like xxxxx.yyyyy.zzzzz. The header typically states the signing algorithm (alg) and token type (typ). The payload holds claims — user id, roles, expiry (exp), issuer (iss), audience (aud), and custom fields.
The signature is created by signing header + payload with a secret (HMAC) or private key (RSA/ECDSA). Recipients recompute the signature to detect tampering. If an attacker changes the payload without re-signing, verification fails.
Base64URL encoding is not encryption. Treat JWT payloads as visible to clients and intermediaries unless you use nested encryption (JWE), which is less common in typical REST APIs.
Decode vs verify: what developers must do
Decoding shows JSON for debugging during development. Verification proves the token was issued by your auth service and is still valid. Production APIs must verify on every protected request.
Libraries like jsonwebtoken (Node), PyJWT (Python), or firebase/php-jwt (PHP) handle algorithm allow-lists — critical because the "alg: none" attack historically tricked naive parsers.
ToolSphare's JWT Decoder helps inspect structure during local dev. Paste tokens from staging only; rotate secrets if a production token ever leaks.
Claims you should recognize
exp — expiration Unix timestamp. Reject tokens past this time with clock skew tolerance (30–60 seconds).
nbf — not before. Useful for scheduled access. iat — issued at. aud — intended recipient service. iss — who issued the token.
sub — subject (often user id). scope or permissions arrays gate fine-grained access. Map claims to authorization middleware explicitly — do not trust client-sent role headers alongside an unverified JWT.
Safe debugging workflow
Copy the token from Authorization: Bearer headers in browser devtools or API client logs. Paste into JWT Decoder to view header/payload JSON formatted readably.
Check exp first when APIs return 401 — expired tokens are the most common issue. Compare iss and aud when microservices reject otherwise valid-looking tokens.
Pair with JSON Formatter when APIs return nested error objects alongside token failures. Use Hash Generator only for generating test secrets — never hash production passwords into JWT demos.
Security mistakes to avoid
Storing sensitive PII in JWT payloads bloats tokens and exposes data in logs. JWTs are cached in browsers and mobile secure storage — minimize personal data.
Using symmetric HS256 secrets that are too short or checked into Git is a common breach pattern. Prefer asymmetric RS256/ES256 for multi-service verification with public keys.
Long-lived JWTs without refresh rotation increase theft impact. Use short access tokens + refresh flows, or session cookies with HttpOnly and Secure flags for web apps.
When JWT is not the right choice
Opaque server-side sessions excel when you need instant revocation (ban user now) without maintaining deny lists for stateless JWTs.
OAuth2 access tokens may be opaque depending on provider. Do not assume every bearer string is a JWT — inspect format first.
For first-party SPAs, consider backend-for-frontend patterns that keep tokens off browser JavaScript entirely.
Часто задаваемые вопросы
Is it safe to decode a JWT online?
Decoding reveals no new secret — the payload is already Base64-encoded. Still, use trusted tools and avoid pasting production tokens that could be replayed before expiry.
Can I change the payload and reuse the token?
Not without breaking the signature unless the server fails to verify. Always verify signatures server-side.
What algorithm should I use?
RS256 or ES256 for distributed systems; HS256 only when one service holds the secret and algorithms are strictly allow-listed.
Why is my decoded JWT showing invalid signature?
Wrong secret/key, altered token, or algorithm mismatch. Confirm you are using the issuer's current JWKS keys.
Where do JWTs appear in real apps?
OAuth login flows, API gateways, microservice auth, mobile app sessions, and webhook verification patterns.
Похожие статьи
Готовы попробовать?
Используйте бесплатные утилиты ToolSphare, чтобы применить полученные знания — без регистрации, мгновенные результаты в вашем браузере.
