Lifetime of an Authorization Code / Pre-Authorized Code

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/2046

Original Reporter: fabian-hk

Section 6.3 of the OIDC4VCI spec introduces the authorization_pending error response, which means that the wallet must use polling to see when the issuer is ready to issue the credential. This means that the authorization code is long-lived, which is against the recommendation in RFC 6749 section 10.5. The same goes for the pre-authorized code, but there the problem is even worse because it can be easily leaked since the credential offer typically uses a custom scheme or the user posts the QR code on their social media thinking the transaction is complete when in fact it is not. I think the lifetime of the authorization code and the pre-authorized code should be as short as possible to improve security. Also, this mechanism is sort of a duplicate of the idea of the deferred credential endpoint, which makes the implementation more complex without adding any functionality.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: danielfett

The fact that to use authorization_pending the auth code or pre-auth code must be valid for longer than absolutely necessary is really bad, especially in the pre-auth code case. It would be much better to issue an access token immediately and then defer issuance using the deferred credential endpoint.

[tlodderstedt]

We have the authorization pending in the spec to allow implementations to issue an access token in the very moment the authorization has been processed (which is the standard OAuth philosophy). Issuing an access token that is not fully authorized can create all sorts of problems since the authorization associated with the access token will vary.

Deferred issuance is intended to be used in situations where the issuance is approved but the issuer needs more time to collect the data and mint the credentials. I'm not sure deferred authorization can be folded into deferred issuance, but if implementers confirm that, I'm absolutely fine with dropping deferred authorization.

[tlodderstedt]

On the original issue: what would we consider an acceptable lifetime? In the end there is a co-relation between entropy of the code and acceptable lifetime, right? Plus, we have PKCE or user_pin to further protect the authorization code from replay. So what is the severity of the issue?

[danielfett]

One problem I see is that the auth code is only protected by PKCE. When the token request leaks (e.g., through a log file in a TLS-terminating reverse proxy) and the code is not invalidated (because it cannot be redeemed yet), the attacker has both time and all information needed to repeat this request.

This is less protection than the auth code in a normal flow has, as there the request usually suceeds and the attacker cannot just repeat the request.

This is also considerably less protection than DPoP or MTLS provide for an access token.

[tlodderstedt]

Shall we introduce a new kind of token (grant type) that is used to fetch the result later? This token could be issued via the TLS protected channel, it could even be key bound.

[danielfett]

That seems like an enormous effort for something that could just be folded into deferred issuance. That will be easier to explain, re-uses existing features, causes barely any extra overhead on the client, and has existing coverage by the security analysis.

[tlodderstedt]

I don't think deferred issuance addresses the same use case. The use case for deferred authorization is that something needs to be done before the access token (the authorization) can be issued, record matching, post processing of identification data, approval by someone. Once the access token is issued, the token is good for getting the respective credentials.
Deferred issuance, in my opinion, might be used if the actual issuance is time consuming.

[cobward]

Once the access token is issued, the token is good for getting the respective credentials.

Isn't this just a matter of perspective? Why wouldn't it be possible to use deferred issuance to address the deferred authorization use case?