5 ms·

Yes, you’re doing it wrong. You could store these “claims” in the same backend cache, keyed by the session_id.

by layoutIfNeeded 5y ago

spyspy 5y ago
But maybe it’s useful to have some metadata in the jwt as well that doesn’t need to be verified by the backend?
- ridethebike 5y ago
  That's more or less what we ended up with. We could choose one the following two extremes: a) Store sessionId as a cookie on the browser, pull all details on backend from cache server - requires network call every time when any tiny user detail is needed, not a showstopped and it worked for us for quite a while but we wanted something more convenient. b) Fully stateless backend, keep entire session in JWT - our user's session is on the huge, plus user's session has private data (we declined this option rather quickly) Instead we ended up with JWT which contains sessionId + bunch of most commonly accessed user properties (various identifiers, roles, login time, etc). Now it seems like that somehow I missed this "JWT means stateless" thingy, well, let's see what people say.
  - layoutIfNeeded 5y ago
    So if a user’s role changes (e.g. some privileges are revoked), they can still act in their old role until their token expires? Sounds like you have a security issue. Which website is this again?
    - ridethebike 5y ago
      Privileges for doing anything serious (e.g. perform payments or change security preferences) are not stored in JWT, all checks done on server side. In case of emergency (e.g. we suspect user session has been taken over) we lock user account and purge session from the backend. Without session on backend - JWT won't do much. It's a fintech consumer website (sorry, can't disclose the name).
- fastball 5y ago
  A JWT still needs to be verified by the backend, it just doesn't need to do a database lookup to do so. But if you're statefully storing sessions anyway...
  - ridethebike 5y ago
    Of course, trusting JWT without verifying it first would be madness
- layoutIfNeeded 5y ago
  Sure, but that’s independent from the session_id, which has no place in the JWT.

Yes, you’re doing it wrong. You could store these “claims” in the same backend cache, keyed by the session_id.

spyspy 5y ago

But maybe it’s useful to have some metadata in the jwt as well that doesn’t need to be verified by the backend?

ridethebike 5y ago
That's more or less what we ended up with. We could choose one the following two extremes: a) Store sessionId as a cookie on the browser, pull all details on backend from cache server - requires network call every time when any tiny user detail is needed, not a showstopped and it worked for us for quite a while but we wanted something more convenient. b) Fully stateless backend, keep entire session in JWT - our user's session is on the huge, plus user's session has private data (we declined this option rather quickly) Instead we ended up with JWT which contains sessionId + bunch of most commonly accessed user properties (various identifiers, roles, login time, etc). Now it seems like that somehow I missed this "JWT means stateless" thingy, well, let's see what people say.
- layoutIfNeeded 5y ago
  So if a user’s role changes (e.g. some privileges are revoked), they can still act in their old role until their token expires? Sounds like you have a security issue. Which website is this again?
  - ridethebike 5y ago
    Privileges for doing anything serious (e.g. perform payments or change security preferences) are not stored in JWT, all checks done on server side. In case of emergency (e.g. we suspect user session has been taken over) we lock user account and purge session from the backend. Without session on backend - JWT won't do much. It's a fintech consumer website (sorry, can't disclose the name).
fastball 5y ago
A JWT still needs to be verified by the backend, it just doesn't need to do a database lookup to do so. But if you're statefully storing sessions anyway...
- ridethebike 5y ago
  Of course, trusting JWT without verifying it first would be madness
layoutIfNeeded 5y ago
Sure, but that’s independent from the session_id, which has no place in the JWT.