Generally if you log out with a JWT, most of the time what will happen is you will remove the token from local storage/cookies. Let's say you have an authentication strategy where you're not using refresh tokens (which I recommend you should do), but long lived JWTs such as 1 DAY, 5 DAY, 30 DAY etc. So, if a user "logs out", the user may believe they are logged out but the JWT is technically still usable. By adding them to a blacklist, you have a mechanism to block any further usage of the JWT. Further, you can use the tokens minimum_issued_at to expire the row in your postgres/redis/store after the JWT will have expired and become unusable.
Another good example of being able to blacklist tokens is it provides a mechanism to provide user functionality such as "Force logout on devices" that you might see on things like Gmail and so forth.
Generally if you log out with a JWT, most of the time what will happen is you will remove the token from local storage/cookies. Let's say you have an authentication strategy where you're not using refresh tokens (which I recommend you should do), but long lived JWTs such as 1 DAY, 5 DAY, 30 DAY etc. So, if a user "logs out", the user may believe they are logged out but the JWT is technically still usable. By adding them to a blacklist, you have a mechanism to block any further usage of the JWT. Further, you can use the tokens minimum_issued_at to expire the row in your postgres/redis/store after the JWT will have expired and become unusable.
Another good example of being able to blacklist tokens is it provides a mechanism to provide user functionality such as "Force logout on devices" that you might see on things like Gmail and so forth.
Isn't this very rare (purely theoretical) use case?
If you delete the JWT from users device memory and storage ->
How does someone use a "technically still usable" token if its nowhere to be found?
I assume
It boils down to a principle I adopted a long time ago: Never trust user input.