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?
In general, we try to avoid putting credentials in URLs, because URLs leak places (such as server or proxy logs, browser history, etc.). In some cases, such as OAuth, people have decided that the simplicity of a redirected GET request is worth the risk of putting a credential (the authorization code) in the URL. However, in such cases, the credential really needs to be both short-lived and single-use.
The latter requirement is a problem for JWTs, as there is no way to revoke them; they are valid until they expire, whether that's in seconds or centuries (or until their signature verification key is rotated out). That prevents making them single-use. You could get away with using a JWT instead of a random token, but if so, you should do your best to keep it out of the URL (e.g. send it in a POST request body instead). You can use an automatically-submitting HTML form to do this, for example. The JWT lifetime should also be VERY short, possibly as little as a single-digit number of seconds (most of the time it will be used within a second or two, but sometimes people have very high-latency connections - e.g. over multiple satellite hops - or unreliable connections or overloaded servers, in which case it might take a few seconds to get through).
Note that the secrecy of the authorization code is EXTREMELY important. OAuth2 contains mitigations for some other weaknesses, such as requiring that the redirect URL matches a short list of pre-registered options (mitigates leaking the client secret or even not having one, as in PKCE), or the State parameter (mitigates CSRF even if the server doesn't notice that the user in question never tried to start an OAuth flow). However, if the authorization code is stolen (or is a JWT or similar but can be tampered with) while still valid, then any attacker who is able to perform an OAuth flow themselves can authorize themselves access to the victim's account, by swapping out or modifying the returned authorization code.
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.
Cheers!
