101–110 of 145 posts
It's articles like these that make things more confusing for folks who are learning about auth/session security. It's obvious the author has developed strong convictions without really understanding the subject. I can't make it past the first sentence: > ...utilize JSON Web tokens (JWTs) for session handling instead of cookies. One has nothing to do with the other. You can use a jwt and cookies. You can use a db sess…
It's articles like these that make things more confusing for folks who are learning about auth/session security. It's obvious the author has developed strong convictions without really understanding the subject. I can't make it past the first sentence: > ...utilize JSON Web tokens (JWTs) for session handling instead of cookies. One has nothing to do with the other. You can use a jwt and cookies. You can use a db sess…
It's articles like these that make things more confusing for folks who are learning about auth/session security. It's obvious the author has developed strong convictions without really understanding the subject. I can't make it past the first sentence: > ...utilize JSON Web tokens (JWTs) for session handling instead of cookies. One has nothing to do with the other. You can use a jwt and cookies. You can use a db sess…
I read that as JWTs in a cookie as a replacement for session cookies with data stored on a server. There are nice things about that, but with a fail safe logout mechanism via server side revocation lists JWTs are not that stateless anymore.
EDIT: I do agree that the article misses the point a bit, but I also agree with the article that sessions cookies are wonderful and you almost always should use that instead. It all depends on your environment. One thing I can say: never use Active Directory as a token server the amount of glue you need is insane.
The general idea of the blog post is correct, but so many things are worded in slightly incorrect ways. I think this blog post needs a few edits. > JSON Web tokens (JWTs) for session handling instead of cookies. JWT and cookies aren't mutually exclusive, you can put a jwt in a cookie, unless it's too big. There are two issues: Where do you store a sessions key, and how you create the session key. The author correctly…
The title should have been “Stop using localstorage for user sessions”. JWTs have a lot of issues, but they do work without localstorage/XSS being involved.
It's articles like these that make things more confusing for folks who are learning about auth/session security. It's obvious the author has developed strong convictions without really understanding the subject. I can't make it past the first sentence: > ...utilize JSON Web tokens (JWTs) for session handling instead of cookies. One has nothing to do with the other. You can use a jwt and cookies. You can use a db sess…
JWTs are stateless.
JWTs reduce the distributed system complexity of having every microservice talk to an auth system in the flow of every request. But with that, there are tradeoffs.
You cryptographically sign JWTs, then you don't have to check them against a session/authc/authz system. JWTs come with an expiry, and your systems statelessly trust them until they expire.
A problem is that a user can't revoke a JWT by logging out or changing their password (unless you build extra infra to store the invalidations and fail closed), so if someone steals the JWT, they can continue to redeem it until expiry.
This is what the article is trying to warn against.
Earlier quoted context omitted.
> so all it takes is a little injected script If you can inject javascript, it's game over anyway. > HTTPOnly cookies are safe from XSS attacks. No, you can still do pretty much anything that cookie enables you to do. You just can't get the actual cookie string.
> If you can inject javascript, it's game over anyway. Yeah, but as you pointed out the one thing you can't do is get the cookie. Having the auth token yourself as the attacker is a way different story then just having XSS vulnerabilities. You can still "do" a lot, but you still have to get another user with the token you want to interact with the page with your XSS to "do" what you want.
The general idea of the blog post is correct, but so many things are worded in slightly incorrect ways. I think this blog post needs a few edits. > JSON Web tokens (JWTs) for session handling instead of cookies. JWT and cookies aren't mutually exclusive, you can put a jwt in a cookie, unless it's too big. There are two issues: Where do you store a sessions key, and how you create the session key. The author correctly…
I hate to word it this way, but the problem is that JWTs are misused.
The reason I hate to word it this way because the natural step after “X is misused” is “X is prone to misuse”. Which is usually right. But the reason why JWTs are prone to misuse is partly because the underlying problem is hard (security, authentication, the web) and partly because some of the libraries which work with JWTs provide application developers some footguns.
Go ahead and use JWTs if you want, but spend some time understanding the underlying problem space. Authenticate the token before parsing it. Choose one specific signing algorithm—don’t allow tokens to be signed with any algorithm your JWT library supports.
And yes—simple session IDs, rather than JWTs, are often a good choice. But JWTs are fine too. The obvious reason to use JWTs is to speed up authentication in your front-end somewhat—if your front-end can authenticate a request by validating the JWT, and maybe checking it against a list of revoked tokens, then that means you can start processing the rest of the request without waiting for a network request for authentication.
Stop using "Stop using X" arguments, without offering an alternative.
Exactly. So anyone reading can suggest what's the alternative while still using JWT? I mean how to do it properly?