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?

  • 2
    This really depends on your application. You normally check for user existance on login and then you trust the info in the token that you pass around. With that being said, you should use different secrets or certificates to sign the token on different environments. A token signed in a development environment should not be valid on the production environment or vice-versa. Each environment with its own secret/certificate. – Bogdan Dec 26 '20 at 20:02
  • How does this situation constitute a leak of a secret? Does the signed JWT actually contain a secret? – Andrew Shepherd Jan 1 at 21:53
  • @AndrewShepherd The point is that if the secret had leaked, a malicious user would be able to produce correctly signed but otherwise unexpected JWTs. The assumption is that such a JWT would not exist otherwise, though I think gnasher729 explained quite clearly that there are lots of cases where it would. – August Janse Jan 2 at 8:05

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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