61–70 of 115 posts
- Make the JWT short lived ( 5 minutes)
- Re-freshing the JWT should involve server state (DB hit every 5 minutes, not every request)
- Protect highly-sensitive actions (typically overwrite/delete, but not read / non-overwrite) by requiring a fresh token.
OK, but what's the real alternative here? I'm sick of these JWT hate articles on HN all the time with no universal solution. Why not just use cookies and be done with it? This looks like an advertisement for Redis Enterprise.
You could have short-lived JWT tokens so it wouldn’t matter because they only last 5-10 minutes or less. They could be refreshed or if using OAuth, simply redirect an unauthenticated user and they’ll be reissued based on the cookies stored by the OAuth provider… assuming the redirect doesn’t break your app of course. Alternatives? First, you could live with the possibility that tokens are valid for some period of tim…
This doesn't only apply to the way JWT tokens are usually used for sessions (no persistence). The default session store for Devise (Rails) and .NET Identity is cookies, on the client. They are encrypted with a secret key and decrypted for authentication. Identity in particular allows you to store any number of "claims" in the cookie, such as a username or role. Because the cookies are signed and HTTP only, this is sa…
1. Logging out deletes the cookie, you are really logged out. If your session cookie got stolen, you have other issues but I don't think this is really a matter of being 'logged out'. It is pretty easy to implement 'revoke all sessions for this user' type of logic with Devise and Devise does this of the box when a user changes their password.
2. Permissions are orthagonal to Devise. Devise stores the user ID in the session and loads the user model on every request, any permissions / blocking system would chain from there.
3. I can't think of anything that devise stores in the session where staleness would matter, other than things intended to be checked for staleness, like the salt that is used for the aforementioned revoke all sessions on password change functionality.
Holy hyperbole, Batman. This is just a straight marketing post for Redis.
> Security should be binary. Either technology is secure or it’s not. From my experience, that's not the case for almost anything. In fact, I'd consider it a dangerous position.
> Security should be binary. Either technology is secure or it’s not. From my experience, that's not the case for almost anything. In fact, I'd consider it a dangerous position.
> Security should be binary. Either technology is secure or it’s not. From my experience, that's not the case for almost anything. In fact, I'd consider it a dangerous position.
If you’re handling sensitive data, you have to understand the tools you’re using and what their relative weaknesses are. Best practices are nice. But it’s far too easy to make a mistake following them if you don’t understand the principles behind them.
“X is always secure” is a great way to ensure X is not implemented correctly.