I'm implementing an OAuth 2.0 Authorization Code grant type flow and considering to use a very short-lived JWT as the authorization code so this step doesn't require a database.

I understand that this code is usually persisted and removed after it's used, but are there any significant security risks of using a JWT instead?


Are you trying to avoid the use of regular authorization codes to avoid implementing the logic behind persisting them and expiring them once they have been used? Or do you have an impediment to roll out a database for that?

I think that if you do it with a JWT, you would still need to embed an id in the payload to identify the token and see if it matches the one you are expecting for a particular client, and for that you would need to keep record of which tokens were given out to which clients. Were you thinking of doing it differently?

I don't know the specifics of your use case, but generally speaking I would advise against doing something that is not commonly done in crypto. And if you can avoid doing the implementation of the server yourself, that would be better as well.

Let me know what you think about this.


  • We do have a database available, but I was wondering if we need it because not storing these codes would save some space and slightly increase performance. These benefits might be neglectable but if there are no significant security downsides to using JWTs then we might as well use those. – Duncan Luk Aug 11 '20 at 9: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.