Hacker News Reader

Comment by jakelazaroff | Hacker News Reader

Stateless JWT for auth is one of the worst trends to catch on in the past few years. Don’t do it – always check your tokens against a database. Otherwise, if someone compromises an account or gets their hands on a token, there’s basically nothing you can do to stop them.

View on HN

Side note, the idea of JWT without verifying the token against a database, made me doubt what I was doing.

I wasted too many cycles trying to understand how it was secure while debating how much latency my database check was introducing on every single request compared to those simply using the JWT as-is.

It has made something I considered "settled" to be a time-sink.

They don't make a ton of sense until your public-facing services get kinda mesh-like. If it's all in one DB, including authorization and authentication data, and you never have one service requesting resources from other services on behalf of a user, they're probably overkill and regular sessions would be fine.

(Nb. I've not personally seen them used in a case for which they make sense, yet, but only in smaller projects because they're trendy)

I'm currently implementing auth with JWTs. I've settled on shortlived access tokens and long lived refresh tokens. The refresh tokens get validated against a blacklist. This way you get the best of both worlds, you minimize db access while at the same time have the ability to revoke tokens.

Another thing one must be aware of with JWTs is protecting your users against XSS and CSRF's. Make sure your shortlived token is stored on localStorage and the refresh one is stored in a cookie.

Why not store short lived token in a cookie as well?

Because then you can be vulnerable to csrf attack. For example if someone tricks you into clicking www.mysite.com/api/delete-account

CSRF attacks can be prevented using same-site policy with cookies.

That is true but it will not protect against all forms of CSRF, for example you'll be vulnerable if you have user generated content that's not sanitized properly. On the refresh_token cookie I have sameSite and httpOnly set.

Same story for any session token that isn't rotated on every request. And even then, if they get the latest one you're out of luck.

Unless you mean blacklisting tokens, then, yes, you do need to check your blacklist, though fanning that out to an edge cache should suffice and keep you from needing to hit your authentication service or database every request. But that's true for any long-lived session token.

The point is that with stateless authentication, you can’t revoke tokens. If a JWT gets compromise, you need to either wait for it to expire or log all users out by rotating the signing key.

With stateful authentication, solving this is trivial: just check your tokens/sessions/whatever against a centralized database every request.

Reply on news.ycombinator.com