JWTs are widely used but often misconfigured. Follow these practices to avoid common vulnerabilities in token-based authentication.
Pin the expected algorithm (e.g. RS256) on the server. The alg:none attack exploits libraries that accept unsigned tokens. Never accept an algorithm not in your allowlist.
Access JWTs should expire in 5–15 minutes. Use long-lived refresh tokens stored securely (HttpOnly cookies) to re-issue access tokens without re-authentication.
Always validate the issuer (iss), audience (aud), and expiry (exp) claims on every request. A valid signature alone is not sufficient — claims must also be correct.
JWT Security Best Practices exists to avoid the JWT mistakes that survive a successful decode: alg none, the wrong key type, and secrets in source control. It is not a second copy of the tool homepage. The homepage introduces the whole product. This page stays on one job so a search for that job lands on instructions you can follow without hunting through other tabs. Read the result on this page against the input you actually used. A screenshot without the input is not evidence. If the result surprises you, change one thing and run it again before you change your VPN, browser, or server config.
Work through JWT Security Best Practices in order. 1. Pin the algorithms you accept. 2. Reject alg none. 3. Keep HMAC secrets out of the repository. 4. Verify, then check exp and aud. Write down the input and the output together. When you ask someone for help, send both. Repeat the same input once. A stable tool returns the same answer. If it does not, the input changed or the page is talking to a different network path than you think.
A long random-looking payload is not confidentiality. JWT payloads are readable. Putting a password inside a JWT is a leak. Rotating a key means rejecting the old key on a schedule you actually run. Treat the output as a measurement, then decide. RookVPN does not log the contents of a client-side tool, and a measurement is not a promise that every other app on the device behaves the same way. Compare a second path when the decision matters: a terminal command, another browser, or the matching guide linked below.
Example: a library auto-selects the algorithm from the header and an attacker sets alg to none or switches RS256 to HS256 using the public key as the HMAC secret. You pin RS256 and you pass only a public key to the verify function. The decode page will still show the attacker's header. Your API must not follow it.
After you finish JWT Security Best Practices, open the verify page to try a token with the algorithm you intend to allow if the next question is different from the one this page answers. Stay here if you are still on the same job. Extra pages help only when they answer a new question, such as a different algorithm, a different leak channel, or a different file type. The documentation link on this page is the long form of the same workflow, including the checks that do not fit in the tool UI.
Access JWTs should typically expire in 5–15 minutes. Use refresh tokens for session persistence. Shorter expiry limits damage if a token is leaked.
Not natively. JWTs are stateless. Revocation requires a blocklist (redis, database) or very short expiry + refresh rotation to limit exposure windows.
Some libraries accept a JWT with alg set to none, bypassing signature verification. Always pin the expected algorithm and reject none on the server.
Not by default. Anyone can decode the payload. Use encryption only if you actually need hidden claims.
No, not because a client asked for it.
A secret manager, not the ticket and not the token.