I am working on a demo project where I have to implement an authorization server for the OAuth2 flow. I was investigating on the best practices for the authorization code, when I read here that:
Because authorization codes are meant to be short-lived and single-use, you could implement them as self encoded tokens. With this technique, you can avoid storing authorization codes in a database, and instead, encode all of the necessary information into the authorization code itself. You can use either a built-in encryption library of your server-side environment, or a standard such as JSON Web Signature (JWS).
It seems a very interesting approach, but I have some doubts about the single-use. Without a datastore/cache, how can the authentication server know whether it is the first time it sees the auth code (which would be an encoded token)? I mean: I could repeatedly send the same request to exchange the auth code and the authentication server would never block the requests following the first one. Do I need a particular implementation of the JWS, am I doing wrong assumptions, or single-use has another meaning in the article?
Later in the article's series, there is the response:
If you are implementing self-encoded authorization codes, as in our example code, you’ll need to keep track of the tokens that have been used for the lifetime of the token. One way to accomplish this by caching the code in a cache for the lifetime of the code. This way when verifying codes, we can first check if they have already been used by checking the cache for the code. Once the code reaches its expiration date, it will no longer be in the cache, but we can reject it based on the expiration date anyway.
Basically, you still need a sort of datastore/cache to keep track of the "used" authorization codes.