lifetime of authorization codes

[jrod]

Per section 10.5 (Authorization Codes) of the OAuth2 spec:

Authorization codes MUST be short lived and single use. If the authorization server observes multiple attempts to exchange an authorization code for an access token, the authorization server SHOULD attempt to revoke all access tokens already granted based on the compromised authorization code.

In debugging the sparklr-tonr example, it's apparent that the code is stored in-memory when the resource owner grants authorization and the code is removed upon the client's subsequent request for the token -- this honors the single use contract.

However, it appears that a client's subsequent token request can occur at any point in the future provided that the implementation of the storage for AuthorizationCodeServices keeps the code persisted. I understand that this scenario is unlikely, especially due to the recommendation for client authentication during token retrieval, but is there a batch job that enforces an unclaimed lifetime on token retrieval? This would, IMHO, better enforce the short-lived contract.

Also, while stated as SHOULD rather than MUST, is there a plan to keep already-claimed codes persisted (as done for access tokens) in order to map a code used in an illegal token request to the tokens already granted for purposes of revocation?

[enkhchuluun]

You can persist authorization codes using AuthorizationCodeServices, but i guess that the batch which clears unclaimed codes (lived too long) is little out of scope of this library. You can make one.

And second is really good idea that already claimed codes to be persist to detect illegel token request.
I think that if you persist the codes in your db, you can flag or map those already-claimed codes with issued tokens (not deleting) so that you can enforce the revocation process.