[jeremycw]

I remember JWT coming on my radar around 10 years ago during the height of RESTful bikeshedding. It was a "must have" because sessions, being stateful, are not pure REST. Now that we've come off the height of the pure REST fanaticism and have learned about a bunch of issues that JWT causes, is it really better than just having a session id and a session stored on the server? Does it actually provide any technical benefit? Honest question.

[brown9-2]

These are orthogonal concepts. A session ID is just a token that the server uses to lookup some state about the request that presented the token. A JWT is a token that can be used to present a claim of who the requestor is (and the server can verify it). A session ID token doesn’t help my request prove I am who I say I am when I call your API for the first time, unless you’ve implemented some sort of state store that all of your API services and server share.

[hn_throwaway_99]

> unless you’ve implemented some sort of state store that all of your API services and server share.

Yes, it's called session storage, and it used to be incredibly common. These issues are not "orthogonal", because a primary promise of JWTs were the ability to get rid of that shared session storage and just put that identifying info into the signed token.

[rowanG077]

JWT's issues are really quite simple to avoid. Spend a day reading how it works and the pitfalls and you are good. And they offer many advantages over sessions with the only real disadvantage being revocation.