6

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.

Improve this question
2
  • 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, 2018 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, 2018 at 15:00

2 Answers 2

Reset to default
16

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.

Improve this answer
1
  • 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, 2018 at 15:30
2

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.

Improve this answer
4
  • 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, 2018 at 14:30
  • That would be a refresh token
    – Ewan
    Jun 25, 2018 at 14:30
  • Not always. Javascript SPAs can use JWTs for authentication, and commonly aren't provided with refresh tokens afaik.
    – BgrWorker
    Jun 25, 2018 at 14:34
  • well, alternate auth flows are available. But that seems like a bad one to me
    – Ewan
    Jun 25, 2018 at 14:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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