JWT tokens are everywhere -- authentication systems, API authorization, single sign-on. But they're also widely misunderstood and misused. Here's what you actually need to know.
The structure: Header.Payload.Signature. Three base64url-encoded segments separated by dots. The header says which algorithm was used. The payload contains claims (data about the user or token). The signature proves the token wasn't tampered with.
The signature matters most. If you're not verifying the signature, you're not using JWT -- you're using base64-encoded JSON with a false sense of security. Our JWT parser shows you exactly what each segment decodes to, including the header algorithm and all claims.
Security rules that matter:
- Always verify the signature on the server. Always.
- Set reasonable expiration times (15-60 minutes for access tokens).
- Store tokens in httpOnly cookies, not localStorage, if XSS is a concern.
- Never put sensitive data in the payload (it's base64-encoded, not encrypted).
- Use JWT for stateless auth, not for session management with revocation needs.
When NOT to use JWT: You need to revoke tokens immediately (JWT is stateless -- you need a blacklist, which defeats the purpose). Your tokens are small and you don't need the overhead. You're building a simple server-side session system where a session cookie works fine.
JWT vs opaque tokens: Opaque tokens (random strings stored server-side) are simpler to revoke and debug, but require database lookups on every request. JWT trades revocation simplicity for performance -- verify the signature locally, no database needed.
Use our JWT parser to decode and inspect any token, and understand exactly what your auth system is sending.