4 ms·
At least those are well known, no common web framework will save password in clear text, and there is comprehensive literature on how to use SQL and many well w
by Znafon 6y ago
At least those are well known, no common web framework will save password in clear text, and there is comprehensive literature on how to use SQL and many well written ORMs that will make it very hard to shoot yourself in the foot.
For JWT, it's essentially promises of easy authentication process (rarely talking about the hard things like logout) spread like landmines over Medium and blogs, waiting to blow your foot and all your application with it.
- mooreds 6y agoRegarding logout, I think that's a fundamental issue with a stateless solution like JWTs. I mean, the whole point is that it is a self encapsulated token, so you don't have to go back to a central server to check if someone's login session is still valid. So how on earth do you invalidate it? My boss wrote up this article on different ways to revoke JWTs: https://fusionauth.io/learn/expert-advice/tokens/revoking-jwts https://fusionauth.io/learn/expert-advice/tokens/revoking-jw... which examines a few interesting methods.
- dathinab 6y agoFor many applications "slow" logouts are enough, i.e. basically do what is common in OAuth2 setups: - Have a refresh token which is only usable with the (right) auth server and can only be used to generate new access tokens. As it's only usable with the auth server it's easy to revoke (it's kinda like a session cookie). - Keep validity of access tokens short. So by revoking the refresh token the logout will be done in at most highest_refresh_token_start_time + refresh_token_validity. Through sadly any "faster" logout method on a distributed system is indeed quite complex. (Like propagating bloom filter headed blacklists of early revoked access tokens).
- Znafon 6y ago> For many applications "slow" logouts are enough Why? I understand it might be acceptable for the next "Uber for Cats" SaaS but if you protect an account that is actually important, not being able to revoke an access key is an issue. > Keep validity of access tokens short. But then you are actually spamming your authentication service and it even starts to blur the distinction between access token and refresh token. I understand that there is many specific use cases where JWT makes sense like when you have to delegate authentication but for other case which shouldn't be recommending it, not being able to properly logout is not a security practice we should have in 2020 and later.
- user5994461 6y agoWhat better tool do you suggest that can handle logout? It's 2020 and there are none. OpenID Connect with JWT handles logout just fine if you really want it. Call the /oidc/tokeninfo to check the token is valid instead of verifying the signature offline. Of course this doesn't have the benefits of a decentralized token anymore. Can't have the cake and eat it too.
- nextaccountic 6y agoDoing regular, boring authentication using user/password just supports logout out of box.
- poxrud 6y agoSo regular cookie session based auth? There are drawbacks such as managing session state on the server, and increased latency and cpu load, since you now have to have a db call on every action.
- closeparen 6y agoThe argument is that this DB call, or something much like it, is inherently necessary to support logout. It's not something unnecessary that can be optimized away; getting rid of it entails losing functionality.
- tester756 6y ago>rarely talking about the hard things like logout Why hard? You can always black list them
- synthc 6y agoBut then you have have make a database call to check the blacklist, so you might as well use sessions
- tester756 6y agoI'm not sure about it, but what if Logout just removed token from client meanwhile "Logout from all devices" black lists token? I tend to believe that it could be used by gmail, but it's just a guess
- poxrud 6y agoIf you're blacklisting tokens at any point in your application, you then need to check this blacklist.