What? Session tokens have been around for like 30 years now, and every web framework worth using has a rock-solid implementation; you haven't had to do it yourself since Full House was putting out new episodes.
If so, most robust session-based authentication libraries can already store this data for you (e.g. Devise's `trackable` module). Actually locking down the session so it can't be used by different IPs/UAs would require custom code on the server, whether you're using JWTs or session tokens.
So JWTs provide zero advantage here, unless I'm misunderstanding something.
The article presents opaque session tokens - a key to a database table entry that is looked up with every request - as so clearly superior to JWTs as not to be a choice really, because session tokens are simpler and easier to use.
> Actually locking down the session so it can't be used by different IPs/UAs would require custom code on the server, whether you're using JWTs or session tokens.
We agree.
My contention is that after the specific use cases are accommodated, opaque session tokens are not the clear win over JWTs on the grounds of simplicity that the article presents it as.
When using a library that does all of the heavy conceptual lifting and conforms to standards, the level of effort is really 6 of one, half dozen of the other.
I find this argument thoroughly unconvincing.
Furthermore, since JWTs are handled client side, and we agree that custom code is needed on the server for this niche feature, it's less likely that a single auth library would support both the basic authentication features and the server-side verification needed, meaning more "fiddling" is required with the JWT solution vs. something like Devise, which is almost entirely server side and can do most of the heavy lifting for you.
This is incorrect.