3 ms·

One of the secrity experts here at HN always recommends against it for auth. Go to the search box on HN and type "author:tptacek jwt". Make sure you are searchi

One of the secrity experts here at HN always recommends against it for auth. Go to the search box on HN and type "author:tptacek jwt". Make sure you are searching within comments. You will see his multiple responses over the years. I have mostly stuck to plain old server side sessions that are easy to revoke. If anyone is using Go, I highly recommend this library : https://github.com/alexedwards/scs https://github.com/alexedwards/scs

spookthesunset 7y ago
> I have mostly stuck to plain old server side sessions that are easy to revoke. But you have implicitly made a tradeoff. Your front-end infrastructure now has a very strong dependency on your auth server. Any minor hiccup in the auth system will blow up your downstream clients. Worse, in large sites you will be sending a ton of traffic to your auth server. You've also introduced a source of latency to your page-load times as each request now needs to call the auth server to validate the token. Whatever the response time of the auth system now gets added to the front-end response time. Going with tokens that can be validated on the front-end system can dramatically lighten load on your auth system and reduce your front-end response time. The only major trade-off is you can't kick somebody out instantly. The bad-actor can do whatever until the token expires--a knob you control. And even then, for shit that matters, you can always have the front-end server validate the auth token on each request anyway.