A JSON Web Token (JWT) is a signed, URL safe container for claims such as the user's identity and roles. Servers hand it out after login and accept it back as proof of who the caller is, so a weakness in the token or in the way it is issued translates directly into account takeover or privilege escalation.

Rapplex finds tokens in responses, request headers, cookies and URLs and examines each one without sending any additional request. The checks cover the signature algorithm, guessable signing secrets, expiration, secrets inside the payload, header parameters that let the sender choose the verification key, and how the token is transported.

A token's payload is only base64url encoded, not encrypted. Everyone who can see the token can read every claim in it.

1. Always sign, always verify. Verify the signature and reject tokens that are unsigned or that use the none algorithm. Configure the verifier with an allow-list of algorithms instead of trusting the alg header of the token.

2. Use strong keys. Prefer asymmetric algorithms (RS256, ES256, EdDSA). When an HMAC algorithm is required, use a random secret of at least 256 bits that is stored in a secret manager and rotated.

3. Keep tokens short lived. Always set exp, keep access tokens to minutes and use refresh tokens with rotation for longer sessions.

4. Keep the payload minimal. Do not put passwords, keys or personal data into a token. Use an encrypted token (JWE) or a reference token when the content must stay private.

5. Do not trust header supplied keys. Ignore jku, x5u and jwk unless they match a fixed allow-list, and sanitize kid before it is used in a lookup.

6. Transport the token safely. Send it only over HTTPS, in the Authorization header or in a Secure, HttpOnly, SameSite cookie, never in a URL.

• RFC 8725: JSON Web Token Best Current Practices
• OWASP JSON Web Token for Java Cheat Sheet
• OWASP Top 10 - A07:2021 Identification and Authentication Failures
• RFC 7519: JSON Web Token