Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

There are legitimate use cases for a client to replay an authorization code. Connection failures happen. Servers fall over before completing requests. Users hit browser refresh buttons. Permitting replay of authorization codes (assuming valid PKCE, client creds, etc.) allows clients to handle these failure modes simply and gracefully via retries.

Would the prevalence for ASs which cannot enforce an atomic code grant warrant further language against plain PKCE?

What is the practical reason for allowing "plain" PKCE in OAuth 2.1? Are there really use cases out there where SHA-256 is a deal breaker?

—
Annabelle Backman (she/her)
richanna@amazon.com<mailto:richanna@amazon.com>

On Oct 13, 2021, at 11:31 AM, David Waite <david=40alkaline-solutions.com@dmarc.ietf.org<mailto:david=40alkaline-solutions.com@dmarc.ietf.org>> wrote:

I agree that PKCE (with a non-plain operational mode) protects the code from attacker use by the security BCP model (but not necessarily stronger models)

Would the prevalence for ASs which cannot enforce an atomic code grant warrant further language against plain PKCE?

-DW

On Oct 13, 2021, at 11:16 AM, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org<mailto:Michael.Jones=40microsoft.com@dmarc.ietf.org>> wrote:

During today’s call, it was asked whether we should drop the OAuth 2.0 language that:
         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 rationale given was that enforcing one-time use is impractical in distributed authorization server deployments.

Thinking about this some more, at most, we should relax this to:
         The client MUST NOT use the authorization code
         more than once.  If an authorization code is used more than
         once, the authorization server SHOULD deny the request and SHOULD
         revoke (when possible) all tokens previously issued based on
         that authorization code.”

In short, it should remain illegal for the client to try to reuse the authorization code.  We can relax the MUST to SHOULD in the server requirements in recognition of the difficulty of enforcing the MUST.

Code reuse is part of some attack scenarios.  We must not sanction it.

                                                          -- Mike

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth