Per section 10.5 (Authorization Codes) of the OAuth2 spec:
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.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.
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?