Using authorization code for second time should invalidate first access token

[mtommila]

There was a finding in a security audit:
Second attempt to resolve authorization code should revoke previously issued access token.
I.e. if an attacker is able to steal an authorization code (this is highly non-trivial of course) and use it to get an access token, then the second attempt to use the authorization code should return an access token, but invalidate the first access token. This way, if the attacker used the authorization code first (before the legitimate client did), the attacker's access token would be invalid. If the attacker used the authorization code after the legitimate client, then the client would notice that the access token is invalid and something is wrong.
There is also another use case for this functionality. If there is a temporary network problem when the client tries to use the authorization code, the first attempt can fail, but the client could retry using the authorization code. Currently the second call would fail (because the authorization code becomes invalid after the first time it's used). However it could be better if the second call still succeeded but the access token given in the first call would just be invalidated.

[praseodym]

RFC 6749 Section 4.1.2 says:

The authorization code generated by the authorization server. The authorization code MUST expire shortly after it is issued to mitigate the risk of leaks. A maximum authorization code lifetime of 10 minutes is RECOMMENDED. The client MUST NOT use the authorization code more than once. If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code. The authorization code is bound to the client identifier and redirection URI.

You're right that using an authorization code for the second time should invalidate the first access token, but a second call should never return an access token.

[jricher]

When an authorization code is used, we currently remove all references from it from the server. This makes it so that it immediately cannot be used for new access tokens, as per the spec. We do not store a reference to the authorization code in generated tokens, so at present we cannot detect this specific replay attack without adding more checks into the system. This was a design choice in the implementation.