by powvans on 10/3/22, 12:18 AM with 84 comments
by maxpert on 10/3/22, 5:15 AM
by parker_mountain on 10/3/22, 2:37 AM
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.
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
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.
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 :)
> 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.
so basically, if your application is doing its own authn/authz (most monolithic applications), you don't need jwts.
by taywrobel on 10/3/22, 2:58 AM
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.
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.
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.
by petrocrat on 10/3/22, 3:44 AM
by 29athrowaway on 10/3/22, 5:27 AM
- Multi-Factor Authentication Sucks
- Nobody Cares About OAuth or OpenID Connect
- What Happens If Your JWT Is Stolen?
- Why JWTs Suck as Session Tokens
I would rather write an article titled: Why all those blog posts suck
by can16358p on 10/3/22, 6:30 AM
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.
by jongjong on 10/3/22, 3:59 AM
by ChicagoDave on 10/3/22, 8:58 AM
You couldn’t drag me back to server side state management for anything.
OAuth2 and JWT tokens is one of best inventions and has proven itself quite thoroughly.
This article was goofy in 2017 and it’s even goofier now.
by seandoe on 10/3/22, 4:27 AM
Determine ttl by considering the context and then balancing performance/security concerns.
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.
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.
by Myrmornis on 10/3/22, 6:34 AM
by camgunz on 10/3/22, 8:27 AM
[0]: https://securitycryptographywhatever.buzzsprout.com/1822302/...
by somethingAlex on 10/3/22, 7:49 AM
That info wouldn’t be in the session db row either.
>> “ 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”
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.
>> “ The full user object must be pulled out of the cache / database so that the website can properly generate its dynamic page content”
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.
>> “ Almost every web framework loads the user on every incoming request. This includes frameworks like Django, Rails, Express.js”
That’s a framework issue and should be customizable. Not really a JWT vs cookie w/ ID topic
There’s plenty of reasons to choose an ID cookie vs a JWT but the many that the author gives are not among them.
by sgammon on 10/3/22, 5:45 AM
(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
(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 have the database accessible to you. You can still verify your signatures.
(3) Redundant Signing Sounds like this is advice for some framework that signs the session cookie? This is silly.
"You should use Session IDs instead"
Tell me you haven't built a globally distributed system without telling me you haven't built a globally distributed system.
by kache_ on 10/3/22, 6:20 AM
It's basically just signed authentication material
Use it when you need to keep your authentication layer horizontally scalable & stateless
Use it when you're transferring trust to an untrusted system, acting on behalf of a user (SAML, OAuth, OIDC)
that's it
It's just signed material
data size limitation (from the blog) is a big meme (source: me). Just pack it into a protobuf lmao
eventual consistency of a stateful session will hurt you btw
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
the protocols are important for oidc/oath/saml
JWT ISN"T A PROTOCOL
i'm tired, I should go sleep
by senko on 10/3/22, 4:38 AM
by sascha_sl on 10/3/22, 6:01 AM
Someone missed the entire point of audience claims in OIDC - on okta.com no less.
by senko on 10/3/22, 9:52 AM
by shp0ngle on 10/3/22, 7:41 AM
Nobody was ever fired for using JWT for authentication.
by woile on 10/3/22, 8:13 AM
I haven't seen it much discussed, and seems to solve a lot of issues from JWT
by sgammon on 10/3/22, 5:53 AM