Should I check for non-existing users with correctly signed tokens?

Question

I ran into an issue when developing where a user that did not exist, but had a correctly signed JWT, was logged in.

This happened when I absentmindedly logged in using a browser while running the test server. Because I used the same makeshift credentials for the user in both databases, the login succeeded. I then switched back to the development server which caused various problems.

In the end, I added a check that the user existed and a unit test that non-existing, but correctly signed, users are rejected. But in production, the leak of my secret would be a catastrophic failure in itself that should never happen. I was already rejecting incorrectly signed tokens. Does having a check like this make sense, or does it just add needless complexity?

Answer 1

Ask yourself: How MUCH complexity does this check add? Without the check, I suppose you need to check all over the place that logged in users actually exist?

And ask yourself: Is the situation possible? You created the impossible situation during development, so you know it's not impossible. What happens if a user is removed from the system while logged in? Could this happen regularly, or just as a race condition (user is fired and removed from the system just as they try to login and have received their token)?

Now consider that as far as security is concerned, you need to anticipate that there are things you do wrong. So it's better to have a system where mistakes on your side don't compromise security.

Answer 2

Two options:

1. Use a different signing key for each separate user DB. That way tokens cannot be valid in more than one system.
2. Store only a random surrogate key in the token. This key is then mapped to an account server side. This is common when the DB is not distributed. For a distributed DB you'll need replication.