JSON Web Token (JWT) Security Architecture & Best Practices
RFC 7519 • Cryptographic Token Security
1. Anatomical Structure of a JSON Web Token
A standard JWT comprises three Base64URL-encoded parts delimited by periods:
<Header>.<Payload>.<Signature>.
The header declares the cryptographic hashing algorithm (e.g., HS256, RS256), the payload contains application claims (sub, exp, role), and the signature guarantees token integrity.
2. Security Pitfalls: The Danger of Cloud JWT Debuggers
Many public JWT decoders submit token strings to third-party logging servers. If your payload includes sensitive internal user IDs, tenant identifiers, or permission scopes, submitting tokens online violates zero-trust security architecture. STILLFANTASY decodes all tokens entirely inside your local browser via native client-side string manipulations.
3. FAQ
What does the exp claim represent?
The exp claim represents the Unix epoch timestamp after which the token is invalid. Our inspector automatically parses this timestamp into local human-readable time.
Can a JWT be read without the private secret?
Yes. JWT payloads are encoded in standard Base64URL, not encrypted. Anyone holding the token can inspect the claims. Never store unencrypted passwords or API keys inside a JWT.