0

I am working on a Spring Boot web application. The REST APIs are secured by JWT tokens. Currently I have only access token generated (not implemented refresh token concept). My question is related to login/logout of users in this scenario. Most of the blogs suggest that on logout, maintain a list of blacklisted tokens in DB. Would this not lead to unnecessary big list of invalid tokens? I have implemented the other way round. Please let me know the draw back with this approach.

  1. On successful login a bearer access token is generated and I maintain a whitelist of this token in DB as LoggedInUsers.
  2. The JWT filter will check for expiry validity, user info validity and checks if the token is in DB. If all these are true then user has access to API
  3. Upon logout, the token is deleted from LoggedInUsers.
  4. Upon password reset, the token is deleted from LoggedInUsers

This web service will be consumed by both Mobile app and Web browser.

Please let me know your thoughts on this approach.

1 Answer 1

1

If you're going to store every token in the database anyway, you might as well store a blob of session data alongside it, and use a random string for the token, rather than encoding data into the JWT.

Would this not lead to unnecessary big list of invalid tokens?

Consider that an expired token will never be checked against the whitelist or blacklist, so as soon as a token reaches its expiry date, you can delete it from the database either way. In the whitelist case, you have to store all tokens which have not yet expired; in the blacklist, you only have to store those which have been explicitly revoked (e.g due to logging out). So (outside the unlikely scenario of someone repeatedly logging in and out in a short period of time) the blacklist is guaranteed to require a smaller list than the whitelist.

You also mention that you haven't implemented refresh tokens yet - that's actually very relevant, because to save looking up in the blacklist on every request, you can issue very short-lived and task-specific access tokens, and only blacklist the refresh token. This allows code to trust the claims in the JWT without access to the database at all.

4
  • Wouldn't the "blacklisting" cause the situation where you have to possess a token in order to blacklist it? In a situation where an attacker steals a device with a client, you will be unable to blacklist the token (unless you memorized the token :) ) because our user cannot present it. In such a scenario, the user cannot log out even from some other device. The only way is to rotate keys and practically, log out all users. Commented May 23, 2023 at 9:57
  • @BranislavLazic You don't necessarily need the exact token to blacklist it, you can filter based on any field it contains. So you can write an entry like "reject any token for user 42 issued before 13:56", to log out all tokens for a particular user. In some scenarios, you might even have a device ID in the token, so can blacklist based on that; because it's inside the signed token, the attacker can't modify it to avoid the blacklist.
    – IMSoP
    Commented May 23, 2023 at 11:14
  • but if you want know all sessions of the user the best way will be whitelist, is it?
    – Tlaloc-ES
    Commented Dec 29, 2023 at 23:15
  • 1
    @Tlaloc-ES I refer you to the first sentence of my answer: if you are going to whitelist all active sessions, you do not need JWT; just use server-side state. Or, put differently, JWT is a way of allowing you not to know all sessions of the user, when doing so might be complicated and expensive.
    – IMSoP
    Commented Dec 29, 2023 at 23:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.