7 ms·
Stop using JSON Web Tokens for user sessions
- deleted 3y ago[deleted]
- rewmie 3y agoHere's a link to an old Stack Overflow question where it's stressed that JWT should be stored as cookies. https://stackoverflow.com/questions/27067251/where-to-store-jwt-in-browser-how-to-protect-against-csrf https://stackoverflow.com/questions/27067251/where-to-store-... The Stack Overflow question is nearly a decade old. This is hardly new. This is not a JWT issue.
- isodev 3y agoIt's mind-blowing how much stigma there is around native browser features. The web has been around for a long time and there are "out of the box" solutions for many things folks sometimes try to re-invent.
- onethought 3y agoTLDR store session things in cookies with httponly set. Basically nothing to do with jwts. More to do with xss
- quickthrower2 3y agoBut then I need a cookie banner /s
- frizlab 3y agoYou need it for local storage too if I’m not mistaken.
- Sayrus 3y agoYou don't need consent for strictly required cookies for functional purposes. Assuming the user actually logged in on your website, you don't need a banner.
- RedShift1 3y agoYou do NOT need a cookie banner to store a session ID or a JWT.
- sam_lowry_ 3y agobecause these are not cookies, right?
- RedShift1 3y agoNo, because they are functional cookies, you don't need to ask for permission of those. I'm also deriving that you might be conflating the two things. JWT and cookies are two different things, but you can store JWTs in a cookie.
- Rexxar 3y agoThe law has never been about cookies themself but about tracking user and asking their consent for selling/sharing their identifying data for things unrelated to the displayed purpose of the site.
- sam_lowry_ 3y agoIt is, in the minds of many. And FYI it is not even a law.
- jinnko 3y agoAnd set the SameSite attribute to strict to prevent CSRF
- drekembe 3y agoWouldn't SameSite=Lax work just as well to prevent CSRF? It prevents things like malicious forms and image links from other sites.
- marcosdumay 3y agoYes, Lax is the option when you want preventing CSRF and nothing else. I actually don't know any use case for Strict, but it makes sense, so it's probably useful. And None is for when you want to explicitly allow CSRF (what is useful some times). And either way, it's best to always set that flag on sensitive cookies (not only authentication, but anything that leaks user information too), even if it's the documented default, because browsers make quite a mess of their default.
- simonw 3y agoSameSite=strict is weird, because it means if someone follows a link to your we application they will be treated as logged out in the first page they interact with, then logged in on any subsequent navigations they make within your site.
- Maxion 3y agoIt's interesting how much of an upward hill battle it has been for me to argue that JWT tokens need to be stored in cookies rather than LocalStorage. In my latest project, the lead backend dev is convinced it is insecure to store the accessToken in a HTTPOnly cookie, and that it HAS to be stored in LocalStorage.
- duiker101 3y agoWhat was their argument?
- Maxion 3y agoShort lived access token, and long lived refresh token. Upon access token refresh and login, refresh token is also rotated. Refresh token expiry is tens of days, access token some hours. Their opinion is that this is enough security. IMO refresh token is vulnerable being stored in localStorage, and relying on users logging in and/or triggering token refresh to rotate refresh token is not really that great.
- isodev 3y agoI'm curious what were their reasons - it's hard to imagine how localStorage would be "more secure" than http only cookies. It's not a zero-sum situation. There are risks and vulnerabilities in every approach, that's why we as web devs take advantage of multiple safeguards to ensure safety when sensitive information is to be transmitted over the wire.
- Ironlink 3y agoMy best guess is that they are thinking of CSRF. With cookies, requests automatically carry the token, whereas with local storage you need to explicitly add the token. However, CORS does a lot to improve this situation. I note that CORS allows posting form data without pre-flight, but it is not immediately clear to me if posting a form cross domain will send cookies.
- 3y ago
- zaffe 3y agoAh, here we go again
- Maxion 3y agoIt's still a bit weird how there's no universal gold standard way to handle authentication with websites. JWT is the closest there is, and there are still enough open ends with it for there to be as many ways to implement it as there are developers.
- d-z-m 3y agoNot sure if I could bring myself to call JWT for website authentication the "gold standard". I'd give the title to HTTP Basic Auth first.
- marcosdumay 3y ago> there's no universal gold standard way to handle authentication with websites Hum... HTTP has an entire authentication header. There is also an entire set of standard practices to authenticate by cookies. The only thing there isn't a standard is for handling authentication data with random code. As that's a pretty stupid thing to do.
- embik 3y agoIt would be helpful if the post not only told you what to _not_ do (especially when it is a frequently done thing) but offered any sort of alternative.
- andybak 3y agoCookie based session logins like everyone used to use?
- sam_lowry_ 3y agoI work for ab EU government, and cookies are a no-go because of cookies directive, so we use JWT and auth the javscript engine, not the browser. This leads to a multitude if problems, but who cares?
- tester756 3y ago>and cookies are a no-go because of cookies directive haha, what?! this is not true.
- andybak 3y agoThis makes no sense. The law didn't specify cookies specifically, it is agnostic about the technical implemention, surely? Is this a clueless manager thing?
- sam_lowry_ 3y agoNot a manager thing, it is a consensus in at least one major EU government sweatshop. Go figure.
- uxp8u61q 3y agoThat's bullshit. Even ec.europa.eu (the European Commission's website - I have to login there from time to time) sets session cookies on my browsers. Either you've misunderstood what's asked of you, or your manager has, or someone higher up in your organization. But the "cookie directive" has never prevented anyone from using cookies altogether. You don't even need to ask for consent for a session cookie.
- oopsthrowpass 3y agoIn my opinion there are 2 good approaches: If you really need to use JWT-s then store the refresh (just normal UUID looking token that is validated on the backend) token in a httpOnly cookie and JWT in local/session storage, use 10-15 minutes expiration and you are somewhat OK on logout= (the XSS is still maybe exploitable). On logout make sure to invalidate the refresh token. In my opinion a better way is to just use a good old encrypted/signed/httpOnly/sameSite UUID=123 cookie, convert that to a JWT in your APIGW/BFF when talking to backends. I would not try to cram JWT-s into cookies they are too big, but maybe these days nobody cares about the extra bytes
- mewpmewp2 3y ago> I would not try to cram JWT-s into cookies they are too big, but maybe these days nobody cares about the extra bytes Why does the length matter compared to when they are sent with cookies or with a special header?
- mort96 3y agoCookies are sent with every request, including to every image or script file or style sheet etc etc. When sent as a separate header, you only set it to API requests.
- mewpmewp2 3y agoYou could use the Path prefix to only send to API endpoints where request has to be authenticated? Or many usually have separate domain/subdomain names for API and static content in the first place. I think having a separate prefix/subdomain would be generally good practice for defining scope which should be authed as well.
- oopsthrowpass 3y agoYeah, fair point, maybe could get some wins if serving assets from same domain, but probably should use a CDN for that on different domain
- deleted 3y ago[deleted]
- had-rien 3y agoI've been exploring best practices for session storage, and it seems like using HTTP-only cookies the only secure choice. However, I've hit a roadblock when trying to implement a login feature within an iframe, especially with Safari disabling cookie functionality in iframes. This has left me pondering alternatives for secure user authentication within iframes. Has anyone encountered a similar challenge or found a workaround? I'd love to hear your insights and experiences!
- bob1029 3y agoI had a problem with cookies on iOS/safari, so we reached for the last hope: url query args. Works flawlessly now. If you use an external identity provider, you can hypothetically avoid storing any cookies at all in first party terms. All you'd have would be 3rd party AAD tokens or whatever. The only reason we even need first party client state is because we want to allow each user simultaneous app sessions that have lifetime decoupled from IdP semantics. This is what we store in the URL query (a guid). Sessions are still bound to user principals, so you would get yelled at if you tried to screenjack someone else's.
- g-b-r 3y agoKeep in mind that urls end up in logs, that might well not be so well protected
- EE84M3i 3y agoParticularly if you use cdns, tracing, analytics, etc. Also, IIRC a parent frame can retrieve a child frame's current URL no matter what.
- bob1029 3y agoIn our case this is fine. The URL doesn't pass any claims. It is opaque client state bound to a specific identity which is validated by other means.
- SuperCuber 3y agoThis post is about XSS, not JWTs... > For security reasons, it is advisable for users to log out from a web application once they have completed their tasks No, the application should be resistant to XSS instead. Online banking and such are automatically logging out to prevent someone stepping away from the device and another person abusing the logged in session. > Frequently, when a Logout function is present in the application and is implemented with JSON Web Tokens, the application stores the JWT in an insecure location, such as the JavaScript code itself or the local storage in the user’s browser This claim is as valid as "Frequently, when a Logout function is present in the application and is implemented without JSON Web Tokens, the application stores the plaintext password in an insecure location". The storage location is completely independent of whether it's a JWT or not.
- alex_duf 3y ago>No, the application should be resistant to XSS instead Or we can admit that vulnerabilities are a likely possibility, despite all of our efforts. Therefore the most secure approach is to understand that limiting the impact of one vulnerability is a reasonable way of dealing with it. Otherwise you're suggesting running application code as root on the machine isn't a problem, since your application has no vulnerability.
- aidos 3y agoI don’t understand the downvotes here. The application should be as resistant to xss as possible but things do sneak through and we should try to limit the damage in other layers. An example is that you could think you have no xss issues because you use react to do your rendering. Meanwhile you have a window.location = something_from_url which is just as capable of running js code if you’re not careful. Having the auth (whatever it is) in a http only cookie is one protection. Having it time limited is another. For some applications locking it to an ip address might make sense. It’s not an either / or thing.
- marius_k 3y agoUsing xss one might target login form and steal username/password instead of a token. So I do not see argument here against jwt. Sure the xss will have to be more sofisticated(?)
- kaoD 3y agoAs a side question (or rather, what I expected the central point of the article to be instead): how are you supposed to actually use JWT? The point of JWT vs opaque tokens is that you can just inspect the token itself to derive permissions without hitting any sessions in DB, right? This means we need a short-lived access token (5 min or so?) so that sessions are revoked in a reasonable time if the token is stolen somehow (this is already scary to me TBH, someone can still do horrific things in 5 mins of intrusion time, but that's another story). Now my question is... how do you even handle the refresh token then? I understand that long-lived refresh tokens means you can actually go to the DB/microservice/whatever and check if the refresh token has been revoked (via log out for example) since they'll valid for much larger intervals, so you can afford the session lookup... But if a refresh token is long-lived, what is the difference from having an actual long-lived access token? You'll still be handing out access token for a while. I can't see the difference here. What am I missing? EDIT: I could see the point if the threat models for both were different (e.g. having access tokens in memory, refresh tokens in a super safe vault, like e.g. ChatGPT would need to do for actions) but having both refresh+access tokens in the same threat model seems like it does nothing to me.
- oopsthrowpass 3y agoYour refresh token does not need to be a JWT, it needs to be checked once in a blue moon and a server side round trip is OK
- kaoD 3y agoBut I already pointed that out in my question. You didn't address my actual concern.
- growse 3y agoThe access tokens go everywhere, to all services and are much more likely to be accidentally leaked / misappropriated. Refresh tokens are only used when talking (infrequently) to the access token minting service, so the scope of use is much much narrower.
- airza 3y agoOh fuck off. This energy and thinking inside the appsec community (of which i am a working member) is the reason the local _pizza company_ feels the need to have a 12 hour timeout on my mobile phone. Just implement a decent content security policy and then you can have the best of both worlds: stateless backend without having the (incredibly minor) risk of having your jwt token stole on my goddamn pizza website.
- sgift 3y agoThanks. Really. This attitude of "if it's not perfect in face of some ridiculous scenario, it's useless" is why people go full "one password for everything, hanging on my screen". Each time someone falls into one of these absurd usability hazards there's a risk you loose them for everything security-related. And when something bad happens security professionals go "oh, but it is YOUR fault" .. yeah, thanks for nothing. Your job is to solve problems. In the real world. For real people. Start doing it.
- nijave 3y agoMeanwhile, my Gmail linked to multiple other accounts is logged in to for months at a time.
- croola 3y agolook at any web client based authentication system like firebase or amazon cognito from FAANG companies. Cognito by default stores it in local storage, and firebase stores in index db and local storage. You can switch to cookies, but it is not possible to set httponly flag because they are client based (js based). And that's the tip of the iceberg.
- 8organicbits 3y agoThe lack of logout and XSS are problems, but I ran into a couple apps that completely forgot to expire sessions due to lacking framework support. In nodejs's cookie-session and @google-cloud/connect-firestore sessions never expire. This issue impacts downstream software including, awkwardly enough, Google's Passkey demo apps. There isn't interest in fixing this. Make sure your app is actually using a JWT framework, not a lesser version, and implements basic security practices. [1] https://github.com/expressjs/cookie-session https://github.com/expressjs/cookie-session [2] https://github.com/googleapis/nodejs-firestore-session https://github.com/googleapis/nodejs-firestore-session
- rmedaer 3y agoTLDR: You can split the JWT into 3 parts and store them differently in cookies to keep the _payload_ accessible in JavaScript and make the _signature_ inaccessible from the web app. In the following Stackoverflow thread (https://stackoverflow.com/a/60941643 https://stackoverflow.com/a/60941643) I described a way to store a JWT in Cookies while keeping convenient to use payload from the Javascript stack (for instance to display the user name). This is achieved by splitting the JWT in 3 parts (header, payload and signature) and storing it into 3 different Cookies which have different properties. The _header_ and _payload_ would be accessible from the web application while the _signature_ is configured with HttpOnly and therefore unaccessible from the web app. The inconvenient of this method is that you have to reconstruct/concat the 3 parts server side. Disclaimer: it's actually an experiment which has for purpose to get the better of both world and it has not been tested from security standpoint.
- jFriedensreich 3y agoi really don’t understand how the article assumes jwt s are not stored in http only cookies. Jwts are an encoding method you can use them to implement a wide array of usecase and if they are used for sessions of course the security best practices for session cookies have to be met, that has nothing to do with jwts except that they require special thought compared to server side sessions when it comes to things like invalidation.
- jFriedensreich 3y agoand when it comes to reading claims and other data from jwts, no one in its right mind would do that by making the session cookie available directly to js client code, so this is a total straw man argument. this is achieved either by making those available separately with means to validate signature but not usable as session token itself or/and by having a session endpoint on the server that reads and validates the jwt and responds with the data from it with the advantage of being able to also add additional session information that is not encoded in the jwt and only available on the server.
- drekembe 3y agoWeird article. Like others have said, it's mostly about XSS. It's strange that the article doesn't discuss at all where the JWT is stored in that case. It's one thing if it's stored in local storage (I would avoid that) and a completely different thing if it's stored in-memory so that potentially malicious scripts don't have access to that location.
- Aldipower 3y agoJust do not store JWTs in LocalStorage or any JavaScript accessible location. Use secured httpOnly cookies. Validate the JWT on server-side _stateless_. No need for a database. This idea is so good and it works! Just follow best security practice. If you don't, it is not the fault of the JWT. Bad blog article.. Yes, things like Keycloak and such follow _bad practice_. Still not the fault of JWT.
- poxrud 3y agoYou do need a database if you want the ability to log users out server side. This is usually done through a second refresh token.
- Moneysac 3y agoIn a single page application it is necessary to access the JWT with JavaScript. Thats why it is so common to save it in the code directly or in the local storage. It is dangerous though, since a XSS vulnerability can be used to access the JWT. This would be totally different with a cookie that is stored with HttpOnly.
- Aldipower 3y agoNo, why? It is very often not necessary to make this accessible to JavaScript, except you are working with refresh tokens. But this is mostly not necessary and overused.
- roetlich 3y agoThe 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 argues that the session key should be stored in a cookie, but doesn't make any arguments against JWTs, as far as I can tell. > This approach is insecure because essential flags like HTTPOnly are not supported. This wording is odd, because it's the other way around? It's not that HTTPOnly isn't supported when storing the session key in js, but that HTTPOnly enforces that you don't do it in js. > the logout function often merely overwrites the JWT on the client side, leaving user sessions valid until timeout. That's obviously bad, but there are also people who just set a different cookie, without making the previous session cookie invalid. Then the author goes on to explain a possible XSS attack, but fails to mention that in the example XSS would also be very bad without the vulnerable session key. The injected js could do something evil right away, without steeling the session key. (But yes, it's worse with the session key exposed) The author doesn't mention the relatively common flow of using refresh tokens together with short lived session keys. Overall, I think this article can be misleading. A confused beginner could read this article and misinterpret it to mean that protocols like OAuth or OpenID Connect are insecure, just because they use JWTs in some places.
- captn3m0 3y agoThe 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.
- chupapimunyenyo 3y ago> Stop using localstorage for user sessions suggest an alternative approach
- klodolph 3y agoAgreed. 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.
- porridgeraisin 3y agoJust store it in localStorage... It is just fine. If anyone is allowed to inject javascript in your site, samesite=lax httponly cookies aren't gonna help much either.. the attacker can fetch /api/me/delete with credentials: include (just like you would have to do in your js code) and it's game over. And extensions can access httpOnly cookies as well. Not to mention other applications can simply access the plain sqlite db. So really, just use local storage for tokens. This way, if you want to expire sessions via refresh tokens, you can simply layer it on top of this, by setting a refresh token in a cookie and adding some extra logic to the api calls.
- deleted 3y ago[deleted]
- greenthrow 3y agoThis is an extremely low quality article.
- edem 3y agoi have been telling teams for years that jwts are only good for one-off processes. they don't even bother to use jewes, sometimes there is no signature validation. no wonder broken authorization is the top 1 security problem
- simonw 3y ago"For security reasons, it is advisable for users to log out from a web application once they have completed their tasks." Isn't that a net reduction in security? Users are more vulnerable to phishing attacks if you've taught them to constantly login and logout of the applications they use. Much better to have them sign in infrequently but more securely using 2FA.
- plagiarist 3y agoI think I am far less likely to be successfully phished (compared to earlier internet) now that I have a password manager programmatically checking domains to choose credentials. I wouldn't think everyone is doing that, but maybe iOS and Android have kinda nudged the majority to use password managers?
- simonw 3y agoI agree that password managers are a huge win from a security perspective, but sadly I'm willing to bet they are still used by a tiny minority of people, even now they are built in to common operating systems.
- jddj 3y agoAnd fewer still are going to avoid copying and pasting the password in from the password manager if the site doesn't match perfectly.
- random3 3y agoStop using "Stop using X" arguments, without offering an alternative.
- wg0 3y agoExactly. So anyone reading can suggest what's the alternative while still using JWT? I mean how to do it properly?
- chupapimunyenyo 3y agoLocalStorage is enough. The point of using a JWT is to avoid using session cookies. If you store the JWT in a cookie, what's the point? You can just use plain old session cookies. Discord keeps their tokens in localStorage and no riots have happened yet
- adrr 3y agoTerrible article. JWTs can be stored in cookies giving you httponly and samesite. If you have XSS vulnerability, what you store your JWTs or if you use JWT do sessions is the least of your concern. Every request to the domain still has cookies attached even with httponly set, that includes all the AJAX initiated requests. HTTPonly just prevents javascript from reading the cookie. It just prevents cookie theft.
- donatj 3y agoThe problem isn’t so much JWTs for auth, it’s just where you are storing them. The answer here is just to store your session JWTs in HttpOnly secure cookies, something we’ve done for years. It honesty simplifies everything anyway. The client has no need to see it or manipulate it. The client code just watches to see if its requests come back as unauthorized and boops you into the authorization process if you are. No need to manually append any sort of auth onto any request. The cookie jar does it for you automatically. It’s really how you should be doing it already. Only real hitch is you can’t cross domain barriers, but that’s not insurmountable. Couple ways to handle it, we generally prefer a little handshake process and a separate JWT per domain. That said, we try to keep everything on subdomains and set the cookie for .example.com
- uticus 3y agoAgreed. If security needs to extend past domain, you are not using the web in the way the web supports. I appreciate interesting solutions that bend the rules of the underlying technology, but (1) the web needs to be treated as if it is what it actually is, and (2) papering over the parts that cause pain is not helping anything.
- marcosdumay 3y ago> The answer here is just to store your session JWTs in HttpOnly secure cookies And set CORS correctly (probably by not having anything in it), and deal with CSRF, and make sure you don't have any XSS issue. It's definitively not insurmountable. But the XSS problem the article focus on still applies. (You shouldn't have any problem with XSS anyway, it's a solved problem that most of the times shouldn't even require thinking about it to keep it solved.)
- d-z-m 3y ago> Modern web applications (so called single page applications) often utilize JSON Web tokens (JWTs) for session handling instead of cookies I had thought the main way JWTs are stored and transmitted in a web context is via Cookie/Set-Cookie? > This attack would not be possible with a cookie based session mechanism where attributes like HttpOnly would prevents injected JavaScript Code from accessing the JWTs. You can put the JWT inside the HttpOnly cookie, right? What am I missing?
- marcosdumay 3y ago> What am I missing? People using JS frontend frameworks to handle every single feature of the frontend, so that they have to let the cookie unprotected or store the token into a JS-only storage.
- gibsonf1 3y agoHmm, our JWT tokens are recreated using a client secret with each request (OIDC connect PKCE) so article makes no sense.
- jongjong 3y agoThese are all bad arguments which I've heard many times. Once your front end is compromised with an XSS attack, it doesn't matter if you're using cookies with session IDs or JWTs... The attacker can use their malicious script running in the user's browser to make calls to your back end server on behalf of the user since the session ID would be sent along with the request inside the Cookie header. The only added 'protection' of the session ID with cookie approach is that it forces the attacker to perform the attack in-situ inside the user's browser... But that's the best place for the attacker to perform the attack from anyway so it adds no value at all. It wouldn't make sense for the attacker to steal a JWT and then use it to make a request from their personal machine using their own IP address... Note that httpOnly flag when using a cookie also doesn't add much value for the same reason. The hacker doesn't need to know what the session ID is in order to be able to fully compromise an account and do whatever they want with it. The main drawback of JWT is that you can't reliably revoke a token after it has been issued. The solution for that is a combination of: 1. Set a short expiry date. 2. Have some kind of 'isDisabled' (or similar) field on the account (or keep a blacklist of account IDs) which allows you to instantly disable a compromised account so it doesn't matter whether or not they have a valid JWT token. Although the second point means you will need to perform a DB lookup of the account (which some would suggest defeats the purpose of JWT), it's a lot simpler to lookup an account record than having to keep track of a session object and remember to clean it up when the user logs out (while also handling all possible server failure/restart scenarios which would otherwise leave behind stale sessions); managing sessions on the back end can be especially challenging in multi-process and multi-host applications... This is where JWT shines.
- PaulHoule 3y agoYears ago this headline was being spammed all the time by some vendor that was pushing something, just like you’d see “hiring is broken” spammed by triplebyte every day for years.
- jongjong 3y agoInteresting. I thought the exact same thing but shrugged it off as far-fetched... but reading this makes me think twice. I guess in this case, you have a security company advocating against JWT... I guess it could mean that JWT is bad for their business because their business relies on applications to be insecure in order to sell the solution? Or is it some kind of conspiracy against single-sign-on?
- seandoe 3y agoIt'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 session and use a jwt and not use cookies. Etc etc
- richbell 3y agoPresumably they mean session cookies.
- ehutch79 3y agoThen why do people keep sending JWTs with only session tokens, which on the backend they treat like session cookies?
- emj 3y ago> > ...utilize JSON Web tokens (JWTs) for session handling instead of cookies. 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.
- echelon 3y agoThis article can't explain what it's trying to hit at! 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.
- chupapimunyenyo 3y agoNo. Don't tell me what to do
- languagehacker 3y agoHere I was expecting them to say "use PASETO". Suggesting that we use cookies instead is wild.
- g-b-r 3y agoThis seems still largely relevant to me: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...
- stillbourne 3y agoI agree, give everyone a session cookie with an encrypted session id, store JWTs in the http context for the session, make the cookie unreadable by js. If you need to read the properties from the token make an endpoint for that. For god's sake stop giving out the JWTs directly to the client.