4 ms·

> > You are essentially powerless, and cannot 'kill' a session without building complex (and stateful!) infrastructure to explicitly detect and reject them, def

> > 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 manually set), which when it changes forces a re-auth (either just a DB auth session because you've specifically set the conditions such that you only care if PW changed or some other flag set, or a full login procedure). If the same static token is used for all users, all users will need to do this on the next request. If you subdivide your users by some metric (first x characters of username, some modulo of numeric ID) then you can invalidate some subset of the userbase JWT tokens instead. You've now gained the ability to immediately invalidate a JWT tokens as long as you're okay with forcing extra computation on some larger set of completely valid ones at the same time. Edit: Changed wording of last sentence to clarify you don't necessarily have to invalidate all sessions just by invalidating all JWT tokens, as outlined in further comments below.

ale_jrb 8y ago
This is true, but kicking off a large subset of the userbase every time an account is compromised (or more realistically, every time someone changes their password—which should certainly invalidate their old tokens) isn't going to be a valid trade off for most applications with customers.
- kbenson 8y ago
  You don't have to kick them off. You can make it a trigger to just check whether their session has been invalidated. Store last password change date or something similar, and if the db user is still valid and the password date is older than the JWT creation date, just update the JWT and let them continue. If not, require a new login procedure or deny outright, depending on account status. > every time someone changes their password—which should certainly invalidate their old tokens Using a variation of above, you can just reverify the JWT every X minutes, and know that if you change a password for normal reasons all JWT tokens will be invalidated within X minutes. It's a trade off. If you can live with what you're trading (or at least live with it after mitigations are put in place), it might be worth it.
  - unclebucknasty 8y ago
    >It's a trade off But, what are you getting for this added complexity--above and beyond what "traditional" user session management provides?
    - kbenson 8y ago
      You can serve pages that don't require DB access without ever hitting the DB. Static content that is restricted to authed accounts is able to be served immediately and directly. Requests that access resources other then ones shared with the auth system do not need to first access the auth system to verify the account. Even if the auth system is on the same DB as the rest of the content, it's no longer a sequential bottleneck.
      - unclebucknasty 8y ago
        Yeah, I can see scenarios where these features would be useful, but wonder how many architectures truly benefit from it? I'd guess that a good many people implement JWT b/c it's the accepted approach or in premature anticipation of a future scaled-out architecture that would land it more in one of the beneficial scenarios. Of course, if the DB concern is one of performance, then there's also a performance trade-off with JWT since the (sometimes large) token is constantly transferred over the wire and compute is used to decrypt it. That may be faster than a DB-round trip, but it's not free. Of course, "old-school" session-management keeps the auth state in memory server-side, which can be the fastest--though comes with a memory hit. But, constantly processing the token in-memory also assigns a memory penalty (even if slightly more transient). In any case, I think it's like a lot of popular tech that evokes strong reactions on both sides: The success of the tech causes it to be overused, invariably in use-cases for which it isn't as well-suited or was not originally designed. In this case, the important need for session expiration alone makes me question hard whether JWT is a good fit for session management in a lot of user-facing apps. In some cases it will be, but in others, there are probably better solutions.
        kbenson 8y ago
- floatrock 8y ago
  A 'standard' JWT claim is Issued-At ('iat'). If you want lightweight JWT's, you're going to be loading minimal user data serverside anyways (logging, roles, etc.) -- it's trivial to compare the iat timestamp to a 'last change' field in your user object. Of course, this gets to the point of the article -- if you're loading data serverside, that's not reeeaaallly the intended multi-party-claim-exchange use case of JWT's....
marcosdumay 8y ago
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?
- kbenson 8y ago
  It is stateful, but with a minimal amount of state that is global. In that respect, it isn't "defeating the entire point of using stateless JWT tokens to begin with." 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.
  - marcosdumay 8y ago
    To be fair, this discussion is unhealthy being full of hyperbole of both sides. Your were one of the first answers, so there was a lot of lost context. The article has a perfectly nice point, that nearly every site does not need stateless sessions. Keeping them on the database is perfectly fine. The article also has a point that there it is impossible to revoke certificates without shared state. People here have a point in that it is possible to optimize that shared state as much as it is a performance non-problem. Other people here have a point in that this is a hard problem that isn't solved by default, so you either do some low level work creating your revocation list from basically the ground up, or you'll get something that is worse than a database. Yet other people have a point in that it's hard to set your PKI correctly and if you don't want to bother with that, you are better with a standard database implementation. All of those are true.
    - deleted 8y ago
      [deleted]

ale_jrb 8y ago

This is true, but kicking off a large subset of the userbase every time an account is compromised (or more realistically, every time someone changes their password—which should certainly invalidate their old tokens) isn't going to be a valid trade off for most applications with customers.

kbenson 8y ago
You don't have to kick them off. You can make it a trigger to just check whether their session has been invalidated. Store last password change date or something similar, and if the db user is still valid and the password date is older than the JWT creation date, just update the JWT and let them continue. If not, require a new login procedure or deny outright, depending on account status. > every time someone changes their password—which should certainly invalidate their old tokens Using a variation of above, you can just reverify the JWT every X minutes, and know that if you change a password for normal reasons all JWT tokens will be invalidated within X minutes. It's a trade off. If you can live with what you're trading (or at least live with it after mitigations are put in place), it might be worth it.
- unclebucknasty 8y ago
  >It's a trade off But, what are you getting for this added complexity--above and beyond what "traditional" user session management provides?
  - kbenson 8y ago
    You can serve pages that don't require DB access without ever hitting the DB. Static content that is restricted to authed accounts is able to be served immediately and directly. Requests that access resources other then ones shared with the auth system do not need to first access the auth system to verify the account. Even if the auth system is on the same DB as the rest of the content, it's no longer a sequential bottleneck.
    - unclebucknasty 8y ago
      Yeah, I can see scenarios where these features would be useful, but wonder how many architectures truly benefit from it? I'd guess that a good many people implement JWT b/c it's the accepted approach or in premature anticipation of a future scaled-out architecture that would land it more in one of the beneficial scenarios. Of course, if the DB concern is one of performance, then there's also a performance trade-off with JWT since the (sometimes large) token is constantly transferred over the wire and compute is used to decrypt it. That may be faster than a DB-round trip, but it's not free. Of course, "old-school" session-management keeps the auth state in memory server-side, which can be the fastest--though comes with a memory hit. But, constantly processing the token in-memory also assigns a memory penalty (even if slightly more transient). In any case, I think it's like a lot of popular tech that evokes strong reactions on both sides: The success of the tech causes it to be overused, invariably in use-cases for which it isn't as well-suited or was not originally designed. In this case, the important need for session expiration alone makes me question hard whether JWT is a good fit for session management in a lot of user-facing apps. In some cases it will be, but in others, there are probably better solutions.
      - kbenson 8y ago
floatrock 8y ago
A 'standard' JWT claim is Issued-At ('iat'). If you want lightweight JWT's, you're going to be loading minimal user data serverside anyways (logging, roles, etc.) -- it's trivial to compare the iat timestamp to a 'last change' field in your user object. Of course, this gets to the point of the article -- if you're loading data serverside, that's not reeeaaallly the intended multi-party-claim-exchange use case of JWT's....

marcosdumay 8y ago

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?

kbenson 8y ago
It is stateful, but with a minimal amount of state that is global. In that respect, it isn't "defeating the entire point of using stateless JWT tokens to begin with." 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.
- marcosdumay 8y ago
  To be fair, this discussion is unhealthy being full of hyperbole of both sides. Your were one of the first answers, so there was a lot of lost context. The article has a perfectly nice point, that nearly every site does not need stateless sessions. Keeping them on the database is perfectly fine. The article also has a point that there it is impossible to revoke certificates without shared state. People here have a point in that it is possible to optimize that shared state as much as it is a performance non-problem. Other people here have a point in that this is a hard problem that isn't solved by default, so you either do some low level work creating your revocation list from basically the ground up, or you'll get something that is worse than a database. Yet other people have a point in that it's hard to set your PKI correctly and if you don't want to bother with that, you are better with a standard database implementation. All of those are true.
  - deleted 8y ago
    [deleted]