4

While creating/assigning the JWTs to users, should we also store them in our databases?

The negatives/cons of storing tokens in database would be, that all the data in the payload of the JWT token is already stored in the database, hence storing the token will storing the redundant data, also the verification of JWTs happens through the signature keys which do not change for a longer period of time but,

The positives/pro I can see of storing the JWT token in our database would be that even after assigning the token we will have the power to invalidate or deactivate the existing the tokens even before the expiry.

One of the use-cases for storing the tokens would be that tokens will be invalidated when there is an update in the auth scheme and all the old tokens have to be invalidated.

  • Since your major point for storing tokens is session invalidation, take a look at this SO answer: stackoverflow.com/a/23089839/7511741. Also, if you have to invalidate ALL tokens you can just change signature key on the server. This will automatically invalidate every token created with the old key. – BgrWorker Jun 25 '18 at 14:03
  • Just an FYI to issue refresh tokens you have to have some sort of persistence... such as a database. – RandomUs1r Jun 25 '18 at 15:00
7

The positives/pro I can see of storing the JWT token in our database would be that even after assigning the token we will have the power to invalidate or deactivate the existing the tokens even before the expiry

This only happens if you're validating the token against the database, in which case why use JWT? The whole point of having a self-contained, signed token is that you don't need to go to the database to verify that the user is signed in.

  • One of the big selling points for JWT is that they are self-contained. No reason to make a round trip to any servers. You are also in control of how they are maintained. If you go with short duration tokens, and provide a refresh ability, then you really don't need the ability to revoke a token. – Berin Loritsch Jun 25 '18 at 15:30
1

So you have implemented OAuth2 but you have a 'security' specifications from the 90s which say

"the user's session must expire after 15 min"

or

"When the user clicks log out their session is no longer valid"

One way to get around this is to implement token revocation. There are a number of ways of achieving this but storing the tokens on a db and marking them revoked is probably the simplest for a small setup.

The problem with revocation is that it requires instant consistency across all your resource servers, exactly the thing you are trying to get away from!

If you can sell short access token expiry as a superior solution then great, if not you are stuck with what is essentially a hack.

  • You sometimes also have to grant long expiration times for user experience specifications (if your service is something the customer uses once a day/week) – BgrWorker Jun 25 '18 at 14:30
  • That would be a refresh token – Ewan Jun 25 '18 at 14:30
  • Not always. Javascript SPAs can use JWTs for authentication, and commonly aren't provided with refresh tokens afaik. – BgrWorker Jun 25 '18 at 14:34
  • well, alternate auth flows are available. But that seems like a bad one to me – Ewan Jun 25 '18 at 14:39

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.