3 ms·
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
by 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 agoSo 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 agoPrivileges 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).