JWT Decoder

• The "None" Algorithm: Historically, some JWT libraries blindly trusted the alg: "none" header. Attackers could decode a token, elevate their privileges in the payload, set the algorithm to "none", and strip the signature entirely to bypass authentication.
• Secret Exposure: Never put passwords, API keys, or PII (Personally Identifiable Information) in a JWT payload. The payload is merely Base64-encoded, NOT encrypted.

JWTs are popular because they are stateless. The backend server does not need to look up a session ID in a database. Instead, it simply verifies the cryptographic signature of the token using its secret key (or public key for RSA). If the signature is valid, the claims inside the token are trusted.

The JWT standard defines several reserved "Claims" (keys in the payload JSON):

• iss (Issuer): Who created the token.
• sub (Subject): Who the token refers to (usually the User ID).
• exp (Expiration Time): A Unix timestamp of when the token expires.
• aud (Audience): Who the token is intended for.

• Ignoring Expiration: Trusting a token without explicitly checking if the current time is past the exp claim.
• Weak HMAC Keys: Using a short, easily guessable secret key (like "secret123") for HS256. Attackers can brute-force the signature offline and then forge their own valid tokens.