221–230 of 255 posts
Sorry, I'm going to be a contrarian here. JWTs can be good. First, cookies-vs-local storage is a non-issue here. If a JWT is small, it can be put in either location. The only real issue is, should session state be on the client or on the server? Suppose you have an app with large numbers of users, doing hundreds+ of queries per second across many boxes. If you put session state on the server, then you must either 1)…
> If you're using a system that has them built in, lovely, but if you're not, it's a lot of extra work. They're built in with PHP and most Node.js frameworks I've ever worked with. I'm not sure about Python, RoR, etc. web frameworks but the engineering overhead for adopting server-side sessions should approximate 0, since they're usually the default.
Earlier quoted context omitted.
No, you force the JWT to be verified against the DB, which might be as simple as checking if the JWT creation time is older than the password update time in the DB, and if so, force only those users to log in. All the token does is force some extra level of scrutiny. It doesn't mean the JWT has to be invalidated,but it does give you the ability to selectively invalidate specific ones for the cost of extra DB load onc…
I see. Thank you for clarifying. :) Anyway, I'm still not convinced because when it comes to security I feel like it's a better idea to walk the well-trodden path, rather than invent new and exciting mechanisms. JWTs are useful for other stuff, but using them for security requires increasing back-end complexity quite a bit.
Earlier quoted context omitted.
> This means that you cannot, for example, invalidate the session of an attacker after detecting a compromise. You also cannot invalidate old sessions when a user changes their password. Sure you can. Just have a 'date_password_last_changed' field on your user model, and compare that with the issued_at date on the jwt. Since your user model presumably gets retrieved for each authenticated request anyway, there are ze…
Updating the 'date_password_last_changed' will invalidate all the tokens for a user. It solves the purpose but has its own trade offs.
If someone is changing their password because it has potentially been compromised, what is a scenario where you would not want to invalidate all of their existing tokens?
Top reason for me always was : > You cannot invalidate individual JWT tokens And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecti…
How the heck did JWT get such a following with issues like these?
Earlier quoted context omitted.
> > You are essentially powerless, and cannot 'kill' a session without building complex (and stateful!) infrastructure to explicitly detect and reject them, defeating the entire point of using stateless JWT tokens to begin with. I'mnot sure that's entirely true. It's not hard to include an extra static token within the JWT which is delivered to the servers through an alternative method (pushed with production, or man…
Well, you are adding infrastructure to explicitly reject the tokens. It is stateful infrastructure. And you can not reasonably do that if you use the tokens as session holders. So, should I think that you agree with the article?
The point is not to be stateless for its own sake, but to leverage less state in a way that's beneficial (e.g. not having to authenticate every request). If adding back a little bit of state in a different way mitigates the major downsides, that can still be useful if it doesn't entirely negate the benefits already gained.
Earlier quoted context omitted.
>>2. Support a "I need to logout user X function" by storing a blacklist of tokens in your RDBMS. Again though, the whole point of JWT is to completely avoid server-side state management. The moment you store state somewhere (whether a list of valid tokens or a shorter list of invalid tokens) you have re-invented the concept of sessions, so why not use that instead?
How about instead of "the whole point of JWT is to completely avoid server-side state management" we think of it as "the whole point of JWT is to reduce the overheads of server-side state management". In my answer above, I was pretty clear about how the load on the database can be significantly reduced with a blacklist and optionally Redis out front, thus allowing JWT to significantly reduce the burden on the databas…
Furthermore, you can store the session information in Redis by ID, too, to reduce DB burden.
Earlier quoted context omitted.
> JWT (I was completely ignorant of it beforehand - cookies all the way) JWTs can be stored in cookies. So I don't understand why you say this.
Oh I'm not aware of the means of using JWT you describe. I think the context of this article is using JWT exclusively, and by the looks of things plenty of people are doing just that.
>A lot of people mistakenly try to compare "cookies vs. JWT". This comparison makes no sense at all, and it's comparing apples to oranges - cookies are a storage mechanism, whereas JWT tokens are cryptographically signed tokens.
There's no such thing as "JWT exclusively". The JWT is just a chunk of data; it has to be stored somewhere, either in a cookie or in local storage.
Earlier quoted context omitted.
The way we do it is with a long lived JWT (LLJWT) and short lived jwt (SLJWT). Our LLJWT lasts for a long time (think years) and is only able to to request a SLJWT, it alone has no abilities. Inside the LLJWT we store a UUID that we also store in the DB. The SLJWT is only valid for 1hr (we are testing on bringing that down to like 10min or so) and when it expires you have to use the LLJWT to request a new SLJWT. If a…
Right, but then you just added state and re-invented sessions, in a round-about way.
Edit: One more point, we also like how JWT's are language agnostic so that we can jump between languages very easily if needed and still use the exact same concepts. Sharing sessions between, say, Java and PHP is not something that is simple/fun/easy to do. JWT's are also easier for us to reason around with, maybe it's just me or my team but I see them as more finite than sessions.
Earlier quoted context omitted.
The way we do it is with a long lived JWT (LLJWT) and short lived jwt (SLJWT). Our LLJWT lasts for a long time (think years) and is only able to to request a SLJWT, it alone has no abilities. Inside the LLJWT we store a UUID that we also store in the DB. The SLJWT is only valid for 1hr (we are testing on bringing that down to like 10min or so) and when it expires you have to use the LLJWT to request a new SLJWT. If a…
If you need to access the DB to check if you can emit a new SLJWT, what's the point of the LLJWT? Why not just store that UUID by itself? The SLJWT does seem useful, but 1h seems too much; if I fear someone might be (for example) accessing my email account using a stolen or hijacked device, they can do plenty of damage in that time. Do you make it clear to the user that their request for a remote sign out might take…
It doesn't have to hit the DB, it could hit memcache or similar caching layer. It also means we could separate this table out from our main DB. We have done neither because it hasn't been an issue (performance-wise) yet.
> Why not just store that UUID by itself?
We could do that, our thought process was that we wanted everything to be a JWT and we liked the ability to, given a JWT, know who it was issued to, when it was issues, and when it expires, all without going to the DB.
> The SLJWT does seem useful, but 1h seems too much; if I fear someone might be (for example) accessing my email account using a stolen or hijacked device, they can do plenty of damage in that time. Do you make it clear to the user that their request for a remote sign out might take that long to be applied?
Totally agree on 1hr being too long and that is why we are planning on lowering it. We have technical reasons (legacy apps that we are trying to get updated) that will not work with lower than 1 hour (I won't bore people here with the details and there are workarounds but we haven't implemented them yet)