How To Use Jwt Tokens Securely
📖 Bu rehber ToolPazar ekibi tarafından hazırlanmıştır. Tüm araçlarımız ücretsiz ve reklamsızdır.
The anatomy — three parts, dot-separated
JSON Web Tokens are everywhere — OAuth flows, API auth, session management, service-to-service calls. They’re also one of the most-misused pieces of auth infrastructure. The spec is small; the mistakes are many: storing secrets in the payload, trusting the “alg” header, leaving tokens alive too long, shipping them to localStorage where any XSS can steal them. This guide walks through what a JWT actually is, how to verify one properly, the security pitfalls with real-world consequences, and when to use JWTs vs. a plain session.
How signing works — HS256 vs RS256
Related: the “HMAC with public key as secret” attack. Server expects RS256 (public key verifies); attacker sends HS256 token signed with the server’s public key as the secret; vulnerable libraries use the public key as an HMAC secret and verify. Fix: lock algorithms explicitly.
The “alg: none” attack
For mobile apps: secure enclave (iOS Keychain, Android Keystore). Never plain SharedPreferences or UserDefaults for tokens.
Expiration — the most-overlooked field
A classic mistake: using JWT for an app with a single backend and no cross-service needs. You get all the downsides (hard to revoke, token-bloat claims) with none of the benefits.
Storage — the front-end question
Stateless tokens can’t easily be revoked. If a token leaks, short expirations are your main defense.
JWT vs server-side sessions — when to pick which
For true revocation, options:
Revocation — the hard problem
Verifying the signature is only step one. After signature passes, validate:
Claim validation — don’t trust the decode
Signed with RS256 or HS256 (not “none”).
Common mistakes
Has exp. Ideally short (minutes for access tokens).
The quick “is my JWT OK” checklist
Payload has no secrets.
Run the numbers
Verifier explicitly specifies expected algorithm.