3 ms·

I asked this question below, but how do you use the payload to select the correct salt from the database in order to verify the signature before verifying the s

I asked this question below, but how do you use the payload to select the correct salt from the database in order to verify the signature before verifying the signature and confirming that the payload is valid?

merb 10y ago
one way would be: - generate the salt - generate the jwt - use the header base64 string as the key for your database - store the salt with the header base64 as the key in your database maybe? just one idea, basically when you are > 100.000 users you barely invalidate a single token. mostly you would kill of your secret which will invalidate any token anyway. but there are numerous ways of doing so. Edit: to the poster after me: actually we never needed to logout a single user. but actually our authorization is not stored in our JWT so if we want to kill a user off, we could just remove any rights from him so he gets a site where he needs to either logout or refresh (which will show him the same site again).
- mwpmaybe 10y ago
  Invalidating the site secret is my go-to strategy right now, but I have wondered how to sign out a single user across all their logged-in devices. Anyway, this idea is interesting and would be pretty straightforward to implement. Thanks!
  - ponyous 10y ago
    Maybe you could salt the secret per user and store it in the DB. This would allow users to have a feature like "Logout from all devices". I am not sure how you would query the database to get the salt? JWT as key and salt as value? Or maybe sending userId with each request? Anyone know any good articles I can read on the topic?
  - numbsafari 10y ago
    The point is to avoid all the database updates. So, I would recommend not going that route. If you need to sign out a user across all logged-in sessions, use a revocation list based on UID, rather than token-id.
    - merb 10y ago
      yep probably the better idea. eventually we combine sessions and JWT Tokens. The session id is kind of a refresh token that refreshes the token if it was expired and the user didn't generate a new token in less than one minute. than it will use the session id will query the database and create a new token if the session is still valid.

merb 10y ago

one way would be: - generate the salt - generate the jwt - use the header base64 string as the key for your database - store the salt with the header base64 as the key in your database maybe? just one idea, basically when you are > 100.000 users you barely invalidate a single token. mostly you would kill of your secret which will invalidate any token anyway. but there are numerous ways of doing so. Edit: to the poster after me: actually we never needed to logout a single user. but actually our authorization is not stored in our JWT so if we want to kill a user off, we could just remove any rights from him so he gets a site where he needs to either logout or refresh (which will show him the same site again).

mwpmaybe 10y ago
Invalidating the site secret is my go-to strategy right now, but I have wondered how to sign out a single user across all their logged-in devices. Anyway, this idea is interesting and would be pretty straightforward to implement. Thanks!
- ponyous 10y ago
  Maybe you could salt the secret per user and store it in the DB. This would allow users to have a feature like "Logout from all devices". I am not sure how you would query the database to get the salt? JWT as key and salt as value? Or maybe sending userId with each request? Anyone know any good articles I can read on the topic?
- numbsafari 10y ago
  The point is to avoid all the database updates. So, I would recommend not going that route. If you need to sign out a user across all logged-in sessions, use a revocation list based on UID, rather than token-id.
  - merb 10y ago
    yep probably the better idea. eventually we combine sessions and JWT Tokens. The session id is kind of a refresh token that refreshes the token if it was expired and the user didn't generate a new token in less than one minute. than it will use the session id will query the database and create a new token if the session is still valid.