DEV Community: Auth Parse

7 JWT Security Mistakes I See in Almost Every Auth Implementation

Auth Parse — Thu, 06 Aug 2026 20:05:40 +0000

Most JWT security problems don't come from a broken library. They come from a handful of small decisions made once during setup and never revisited: which algorithm to trust, where to store the token, what to actually validate on the way in.

Here are the ones that come up most often, and what to do instead.

1. Trusting the `alg` header instead of specifying it yourself

If your verification code reads the algorithm from the token rather than hardcoding what you expect, you're exposed to algorithm confusion attacks, including the classic alg: none bypass. Always tell your library which algorithm to expect. Never let the token decide for you.

2. Storing tokens in localStorage

Any script running on the page can read localStorage, including a compromised npm package or an XSS payload. HttpOnly cookies with Secure and SameSite flags aren't readable by JavaScript at all, which closes that door completely.

3. Long-lived access tokens with no revocation plan

A JWT can't be "deleted" once issued. If you're not thinking about this before you ship, you're one leaked token away from a bad week. Short expiry (15 minutes is a reasonable default) plus a refresh token you can revoke server-side covers most cases without needing a full blocklist.

4. Skipping claim validation beyond signature checks

A verified signature only proves the token wasn't tampered with. It says nothing about whether it's expired, meant for your service, or issued by who you think. exp, iss, and aud all need explicit checks, a valid signature on an expired or wrongly-scoped token is still a valid signature.

5. Putting sensitive data in the payload

JWT payloads are encoded, not encrypted. Anyone holding the token can read every claim inside it. Roles and IDs are fine. Passwords, full billing details, or anything you wouldn't want in a browser dev tools tab shouldn't be there.

6. Assuming RS256 is automatically safer than HS256

It depends on your setup, not the algorithm name. HS256 is fine for a single service verifying its own tokens. The moment multiple services need to verify independently, RS256's public/private key split is the right tool, but neither one is inherently "more secure" in isolation.

7. Never testing what happens when verification fails

Most teams test the happy path constantly and the failure path never. What does your app actually do with an expired token, a tampered signature, or a token signed by the wrong key? If you don't know the answer, that's worth finding out before an attacker does.

I wrote a longer version of this with code examples and a full FAQ section over on AuthParse: JWT Security Best Practices. If you're debugging a specific provider (Supabase, Clerk, Firebase, NextAuth), there's also a free JWT decoder that runs entirely client-side, nothing you paste is ever sent anywhere.

Curious what others have run into: which of these have actually bitten you in production, and which do you think is overrated as a risk?

HS256 vs RS256: Which JWT Signing Algorithm Does Your Auth Provider Actually Use?

Auth Parse — Wed, 29 Jul 2026 19:48:19 +0000

Decode any JWT header and you'll spot a field like "alg": "RS256". Most devs glance at it and move on , but that one field decides how your tokens get signed, verified, and whether your verification code will actually work in production. Here's the short version.

Why the signing algorithm matters

A JWT's header and payload are just Base64URL anyone can read them. The signature is the only part that proves a token is genuine and untampered. The algorithm determines how that signature is created and checked, and getting it wrong in your verification logic is a real vulnerability, not a theory problem.

HS256: one shared secret

HS256 (HMAC + SHA-256) is symmetric the same secret key signs and verifies the token. Fast, simple, and fine when one backend both issues and checks its own tokens.

The catch: every service that verifies tokens needs that same secret. Share it with more services and you widen the attack surface and rotating it isn't painless either.

RS256: public/private key pair

RS256 (RSA + SHA-256) is asymmetric. A private key signs the token; a public key verifies it. Only the auth server ever holds the private key — everyone else just gets the public one, which is safe to hand out freely.

That makes RS256 the better fit for microservices and public APIs: each service verifies independently, and providers typically expose their public keys via a JWKS endpoint a standard URL of current keys, matched by kid in the token header. The trade-off is a bit more overhead: RSA math is slower, and there's a network dependency for key fetching.

What your auth provider is actually doing

Provider	Algorithm	Notes
Supabase	HS256	Shared secret in your dashboard; can even verify client-side
Clerk	RS256	Rotating key pair, JWKS handled by their SDK
Firebase	RS256	Keys rotate every few hours via Google's JWKS endpoint
NextAuth	HS256 (default)	Uses `NEXTAUTH_SECRET`; also wraps tokens in JWE, which is why you'll see 5 parts instead of 3

The one security trap to know

Some older libraries will accept alg: none meaning no signature check at all. Always explicitly whitelist the algorithm you expect server-side. Never trust whatever the token header claims.

It's not really your choice

The algorithm isn't something you pick at sign-in , it's whatever your auth provider decided. Your job is just to know which one you're dealing with so you debug the right problem when verification fails.

That's the concept. What I didn't get into here: how to actually migrate a live app from HS256 to RS256 without breaking active sessions, a full decision framework for picking one when you're rolling your own auth, the exact JWKS URL format for each provider, and answers to the "can I," "is it always," and "how do I verify without a library" questions that come up constantly. I wrote all of that up on the full post.

If you just want a quick answer right now: paste your own token into the AuthParse decoder , it reads the alg field for you, flags it if it's none, and tells you whether you're looking at HS256 or RS256 without you having to think about it.

JWT vs Session Tokens | What’s the Difference and Which Should You Use?

Auth Parse — Sun, 26 Jul 2026 20:06:00 +0000

JWT vs Session Tokens: The One Sentence That Actually Matters

If you've built more than one web app, you've had this argument with a teammate: "just use JWTs" vs "sessions are simpler and safer." Both people are usually right just about different situations, and most explanations never make clear which situation is which.

Here's the one-sentence version that cuts through it: sessions store state on the server and hand the client a reference. JWTs store state on the client and give the server a way to verify it.

Every tradeoff people argue about revocation, scalability, mobile support, database load comes from that one distinction. Once it clicks, the rest stops feeling like opinion and starts feeling like math.

The tradeoff nobody explains well

JWTs are stateless, which is great for performance no database lookup on every request, no shared session store to maintain, works naturally across mobile clients and microservices.

But that same statelessness creates a problem most tutorials gloss over: what actually happens when a user hits "logout"?

With a session, the answer is simple delete the record, done, guaranteed. With a JWT, logout only removes the token from the client. If a copy exists anywhere else — a log file, a network capture, a compromised device it's still perfectly valid until it expires. Depending on your auth provider's defaults, that expiry window could be 60 seconds or 30 days.

The common fixes (short-lived tokens plus refresh tokens, or a server-side blocklist) work , but they come with a catch that's genuinely counterintuitive once you see it, and it's the part of this that trips up the most experienced developers.

Where this actually lands for you

The right answer depends on:

whether your primary client is a browser, a mobile app, or another service
whether you're already on a provider like Supabase, Clerk, or Firebase (and what they default to — it's not the same across all three)
whether "instant logout" is a nice-to-have or a hard requirement for your app

There's a specific decision guide for exactly this, plus a breakdown of what Supabase, Clerk, Firebase, and NextAuth are each doing under the hood by default (they're not all making the same choice, and one of them is quietly doing something most of its users don't realize) I laid all of it out in the full piece:

Read the full breakdown on AuthParse →

AuthParse is a free, client-side JWT decoder built for developers working with Supabase, Clerk, Firebase, and NextAuth , nothing you paste is ever stored or sent to a server.