2

I am building an authentication service with python and flask and I use MongoDB to store user details.

When a user sends a request on an API that enforce the authentication service, I get the token from the request, check if the JWT is valid (I use RSA256), check if the exp is valid, and ultimately I retrieve the auth dict from the payload and check if the current API is authorised for this user. If all the previous checks are ok, I authorize the user and log him.

In my JWT payload, I also have the userId, should I use it to check that the user exists by calling the db ? In addition to that, should I also get the auth dict from the db or can I use the one from the payload ?

By default, I trust the JWT and don’t cross check the infos with the db, is it alright ?

Thanks for your help !

1

first question

should I check that the user exists by calling the db ?

Nope. Don’t check the user first.

Two reasons.

  1. Denial of service. Ideally you never make a DB call until after you trust the request’s origin. If I’m a bad guy, and I can make your DB do work, it doesn’t matter how many elastic instances you spin up on AWS, you still have a small number of database instances.

  2. Information leakage. You usually want to fail the same way if when the request is unauthenticated. If you ask the dB, then check the jwt, then fail, the attacker will know that the user was valid. If you check the dB and the user is not valid the attacker will know the user was invalid. Therefore to not leak information usually you will always check the jwt even if the dB call says the user is invalid.

  3. Similar to 1, checking a jwt is faster than a dB call.

second question

should I also get the auth dict from the db or can I use the one from the payload ?

This depends but the core of the question is can you trust the information the client sends you?

  1. Make sure your crypto stuff is safe and secure. If you trust your implementation/ library / key handling / key generation then you should be able to trust the crypto Algorithm to defend against tampering.
  2. If the data changes often you have to worry about it becoming stale and would want to check the dB more often.
4
  • Thanks a lot for you answer ! However, I don't really get the 1.2 point, with the 401/403 in x+y time, could you rephrase it please ? For the point 2, my implementation is simple and safe and I'm using Kubernetes secrets to keep the keys safe. And the data are only changing once every 2 months or so, so it should be ok ! But just to make things clear, your advise is to not check user on db at all, right ? Or just check it after checking the JWT is valid ?
    – Agudolive
    Jul 11 at 8:02
  • Updated point 1.2.
    – Jonathan
    Jul 11 at 15:18
  • Advice is to skip the dB check
    – Jonathan
    Jul 11 at 15:19
  • The whole point of JWT is being able to skip things like DB lookups, else you could use a regular token.
    – René Roth
    Jul 11 at 20:10

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.