121–130 of 159 posts
I don't really get the point of JWT these days with SameSite and CSP-headers available. And from the backend perspective, most frameworks have session tracking built-in with cookies so it's super easy to dismiss one or all clients. With JWT however, that rarely exist and you need to re-implement the whole session-shebang in order to keep track of the clients.
I love JWTs between servers. Between servers and clients, you just end up remaking cookies/sessions. Strictly my experience/opinion. Glad to hear from others.
Cookies are only controlled by the server but obviously can be negotiated for with a secret. JWTs have a mutual secret component built in and far cooler sounding ... stuff. So both ends have to trust the other and prove it with JWT and when cookies are in play, you takes your chances - you can use mutual TLS to get the same trust that JWT gives. I have a web app that I'm doing sysops for which ended up with both. The…
The problem I've got with JWTs is that actually you can rarely (never, really in my experience?) assume anything in the JWT apart from user id are valid for a long period of time. For the most simple use case of an client auth state; you want to be able to revoke auth straight away if an account is compromised. This means you have to check the auth database for every request anyway, and you probably could have got wh…
If a token is not a JWT is it really a “Bearer” token?
Every time I want to use a JWT, it seems like it's the suboptimal choice, so I've never found a genuine use case for them. Most recently, I wanted to implement 2FA w/ TOTP. I figure I'll use 1 cookie for the session, and another cookie as a TOTP bypass. If the user doesn't have a 2FA bypass cookie, then they have to complete the 2FA challenge. Great, so user submits username & password like normal, if they pass but d…
Paseto is better https://paseto.io/ , but unfortunately OAuth forces the usage of JWT.
> OAuth forces the usage of JWT. OAuth doesn't, OIDC does for the ID token[0]. OAuth, at least the inital RFCs, were released 3 years before JWT was defined. But many extensions of OAuth do require or support JWTs. Either way, I'm just not sure the demand is there. My employer has had an open issue for Pasteo[1] for years but hasn't seen much community support. Some other interesting comments here[2]. Looks like most…
It shouldn't be about demand. It's about solving the danger of these poorly designed APIs to improve overall web security.
Love JWTs but I wish there was a better standard for conveying detailed and compact authorization information, for systems requiring enforcement of complex authorization rules. We experimented once with trying to put permissions on a JWT (more complex than your popular scopes) but that makes them grow quickly. And we experimented with putting role information on JWTs but that results in re-centralization of logic. Ma…
Paseto is better https://paseto.io/ , but unfortunately OAuth forces the usage of JWT.
{ "pay": { "msg": "There are also other options.", "alg": "ES256", "iat": 1748248973, "tmb": "9PcBWntvjAktwfiPp8WxgOyQOwc1h6Lo1UnB_gkWXKk", "typ": "cyphr.me/msg/create" }, "sig": "sHyMrykhsta5etjqH1e5oho0EpEs2FrblQ0DFHQo0aMgKd2V__SQ2Fl2EOSKt8wl65iLmKgIaMVEgCmhtvbUcg" } Verify: https://cozejson.com Spec: https://github.com/Cyphrme/Coze
He discusses the architectural advantages of JWT but also discusses JWTs lacking
"JWTs are a passport without a picture. A very dangerous thing".
His solution: OAuth2 + JWT + Signatures
The problem I've got with JWTs is that actually you can rarely (never, really in my experience?) assume anything in the JWT apart from user id are valid for a long period of time. For the most simple use case of an client auth state; you want to be able to revoke auth straight away if an account is compromised. This means you have to check the auth database for every request anyway, and you probably could have got wh…
I think you have a narrow view. For example, a magic link sent via email can have a substantial validity duration.