Yes for basic websites simple DB based session might be enough. And if you think about these sessions they are essentially opaque and stateful tokens pointing to a row in DB containing the information you need. But saying JWT sucks in plain generic terms is out of context statement, in large micro-service environment if every front-end service starts hitting an identity service the fan out is gonna kill you! You keep a basic set of information in token that is most often used, not every service will need user phone number, and all of his roles. 95% of your read traffic will need some basic ID, email, and basic roles that can be satisfied from JWT token. What OKTA is suggesting essentially is gonna push all the load onto a DB or some sort of datastore, so that it becomes SPOF, and now you have shifted problem to scaling that DB/Datastore. Answer IMO is it depends.
Some concepts to think about:<p>local introspection: validating the validity and lifespan of a jwt by checking it cryptographically. does not need to make a network call, thus very fast and a great way to perform a low stakes operation.<p>remote introspection: validating the integrity and lifespan of a jwt by checking with the server that signed it and/or the server that issued the session. this should happen at least once per call flow, ideally as few times as possible but also every time sensitive information is accessed<p>if you have a heavy call graph, you can do local introspection on everything in the middle. and then, when you go to retrieve pii, do remote introspection.<p>if your token is appropriately short-lived (15 minutes), this means that an attacker can only yield information within that window with token scraping. that means that an attacker can only access data for as long as they have a foothold. i hope you have strong reporting and immutable architecture :)<p>> If you’re building a simple website like the ones described above, then your best bet is to stick with boring, simple, and secure server side sessions. Instead of storing a user ID inside of a JWT, then storing a JWT inside of a cookie: just store the user ID directly inside of the cookie and be done with it.<p>so basically, if your application is doing its own authn/authz (most monolithic applications), you don't need jwts.
This skips over one other big way that I’ve always seen JWT implementations fall over - sign out/session invalidation.<p>A JWT has all the information for verifying its own lifetime contained within it, which is cool in that you don’t need to hit the DB to verify it… until you want to invalidate it before the embedded expiration is hit.<p>Then you need to hit the database or some cache layer to verify that it isn’t invalidated, and now one of the biggest reasons to use it is gone.<p>They do mention that for CRUD operations you’ll need to hit the DB anyways, which is in the same vein as this issue tho.
PASETO tokens are superior to JWT in just about every important way, it's weird how they are so obscure and have not caught on.
[1] <a href="https://paseto.io/" rel="nofollow">https://paseto.io/</a>
Also from the same author (actual titles):<p>- Multi-Factor Authentication Sucks<p>- Nobody Cares About OAuth or OpenID Connect<p>- What Happens If Your JWT Is Stolen?<p>- Why JWTs Suck as Session Tokens<p>I would rather write an article titled: Why all those blog posts suck
While I don't necessarily disagree, I think using the globally accepted way of somehow utilizing JWTs outweigh the marginal and exaggerated (24MB for 100K requests is literally nothing in 2022) benefits.<p>If I use JWT I get widely battle tested library support and near-universal acceptance among developers, which is more than enough for most of the folks to go with JWT IMHO.
JWTs are great for fast, efficient, distributed authentication. You shouldn't store too much stuff in the JWT, just the username and access level is generally enough. The trick is to set it to have a short expiry and keep renewing while the user is online/active.
I’ve been building software for 35 years and web apps since “the beginning.”<p>You couldn’t drag me back to server side state management for anything.<p>OAuth2 and JWT tokens is one of best inventions and has proven itself quite thoroughly.<p>This article was goofy in 2017 and it’s even goofier now.
Jwts are great for micro/multiple services -- no need to hit the auth db on every request.<p>Determine ttl by considering the context and then balancing performance/security concerns.<p>If you need to invalidate a session before the ttl expires, throw the identifier in a memory cache. But I think this is overkill for most applications. Rather, protect important state changes by asking user to enter password or to provide other form of auth.<p>If the frontend wants access to the jwt data, a pattern I like is splitting the jwt by keeping the header and payload in js readable cookie or local storage, then keep the signature in an http only cookie.
I found Security Cryptography Whatever's treatment of the various session token options super informative [0]. I had some vague unformed skeptical opinions about JWTs, and now I have some reasonably informed rational opinions about them, so can recommend.<p>[0]: <a href="https://securitycryptographywhatever.buzzsprout.com/1822302/9020991-what-do-we-do-about-jwt-feat-jonathan-rudenberg" rel="nofollow">https://securitycryptographywhatever.buzzsprout.com/1822302/...</a>
>> “ A mission critical user check needs to run (eg: does this user have enough money in their account to complete the transaction?)”<p>That info wouldn’t be in the session db row either.<p>>> “ A database write needs to occur to persist information (if this information is related to the user, it’s likely that the full user object must also be retrieved from the database”<p>This type of info doesn’t get updated frequently. Email, phone, name, etc, are pretty static. If they are just talking about a join using a userId, well that’s not gonna be any different whether you know the ID from a JWT or normal cookie.<p>>> “ The full user object must be pulled out of the cache / database so that the website can properly generate its dynamic page content”<p>But that’s an upside of keeping more than a cookie with an ID. You can just stash the stuff that doesn’t change much client side (keeping in mind the XSS risks). We certainly don’t pull the user’s email and name every page load even though it’s displayed on every page.<p>>> “ Almost every web framework loads the user on every incoming request. This includes frameworks like Django, Rails, Express.js”<p>That’s a framework issue and should be customizable. Not really a JWT vs cookie w/ ID topic<p>There’s plenty of reasons to choose an ID cookie vs a JWT but the many that the author gives are not among them.
JWTs survive in popularity because, by and large, their size is negligible over the wire, internet speeds get faster (not slower), and key agreement across systems is still a surprisingly complex problem.<p>(1) Size
Factoring Gzip and HTTP/2 header compression into this, size is no longer an issue, but it's still a reasonably good idea to keep claim sizes down. If you don't like using cookies, use a sessionStorage value and affix via XHR! Easy<p>(2) You're Going to Hit The Database Anyway
No you aren't, necessarily? Wth. Also, JWKS paired with JWT gives fantastic rotation security with very minimal configuration across systems. So, maybe you don't even <i>have</i> the database accessible to you. You can still verify your signatures.<p>(3) Redundant Signing
Sounds like this is advice for some framework that signs the session cookie? This is silly.<p>"You should use Session IDs instead"<p>Tell me you haven't built a globally distributed system without telling me you haven't built a globally distributed system.
JWT as a term used to describe signed material should considered harmful (source: me)<p>It's basically just signed authentication material<p>Use it when you need to keep your authentication layer horizontally scalable & stateless<p>Use it when you're transferring trust to an untrusted system, acting on behalf of a user (SAML, OAuth, OIDC)<p>that's it<p>It's just signed material<p>data size limitation (from the blog) is a big meme (source: me). Just pack it into a protobuf lmao<p>eventual consistency of a stateful session will hurt you btw<p>yes yes yes I know. The grey bears gave us protocols, rfcs, etc. MUH PROTOCOLS. just give me a private key and a bud light dude<p>the protocols are important for oidc/oath/saml<p>JWT ISN"T A PROTOCOL<p>i'm tired, I should go sleep
Related recent discussions (different articles on a similar topic):<p><a href="https://news.ycombinator.com/item?id=33019960" rel="nofollow">https://news.ycombinator.com/item?id=33019960</a><p><a href="https://news.ycombinator.com/item?id=33018135" rel="nofollow">https://news.ycombinator.com/item?id=33018135</a>
>In this case the requesting party will have a token to prove their identity, and can forward it to the third (or 4th … nth) service without needing to incur a real-time validation each and every time.<p>Someone missed the entire point of audience claims in OIDC - on okta.com no less.
Randall has also given a number of talks on the topic, so if you prefer watching to reading, have a look at <a href="https://www.youtube.com/watch?v=JdGOb7AxUo0" rel="nofollow">https://www.youtube.com/watch?v=JdGOb7AxUo0</a>
At this point, JWTs are a cargo cult. People do them because everyone else does them, even when it makes 0 reasons in the app itself and they use them as worse session tokens.<p>Nobody was ever fired for using JWT for authentication.
Has anyone tried <a href="https://www.biscuitsec.org/" rel="nofollow">https://www.biscuitsec.org/</a> ?<p>I haven't seen it much discussed, and seems to solve a lot of issues from JWT