While I could agree with the sentiment "consider using opaque auth tokens instead of JWTs in most use cases" I can't get behind the opinion-presented-as-factual-statement tone of the article. There are valid use cases to offload authentication to the client rather than verifying an opaque token with every request. One advantage is that community support for JWTs is large, but home-grown, ad-hoc opaque token solutions not so much. Another is that any claim at all can be stored in the JWT: IP address, user name, opaque token, whatever makes your app secure. While these same claims could be stored in a database, now you have extra overhead and maintenance dealing with them.
I would like to see an open-source project from this author that uses his proposed solution.
IMHO the stateful opaque token approach is simple enough that it can (and often does) get baked into whatever language/framework you’re using to write your app. In addition, the very nature of session tokens is such that the logic for what the token actually means/represents lives in your app, on the server.
So, that may be why we don’t see more “opaque session token” standards/libraries out there as an alternative to JWTs.
But if you want an existing example, Devise for Rails [1] has been around a while.
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.
I would like to see an open-source project from this author that uses his proposed solution.