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.
Binding a session to client details like IP addresses and user agents requires enough fiddling that it's no longer the no brainer to use session tokens over JWTs that the article makes out, is my point.
By "binding a session to client details like IP addresses and user agents" do you mean restricting the session so that only the original IP/UA can make use of the session token?
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.
If I'm understanding correctly, your claim is: when a requirement exists for a niche "session lockdown" feature (likely required by less than a few percent of all sites/apps in existence), implementing the feature requires server side code. Therefore, the article is wrong about server side sessions being the clear winner.
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.
