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

[Daniel Fett <[e-mail]>]

Am 16.10.21 um 01:41 schrieb Mike Jones:
>
> As I see it, the retry in case of network failures should happen by
> performing a new authorization request – not by trying to reuse an
> authorization code – which is indistinguishable from an attack.
>
It only looks like an attack when the code has actually arrived at the
token endpoint on the first try (which the client cannot know, of course).

I think Annabelle's proposal of allowing reuse-on-error has its merits.
The AS can still reject the code when it has seen the same code already,
and the client can then fall back to starting a new authorization request.

-Daniel


>  
>
> Let’s not use OAuth 2.1 as an opportunity to sanction behaviors that
> we can’t distinguish from attacks.
>
>  
>
> The prohibition on clients reusing an authorization code needs to remain.
>
>  
>
>                                                           -- Mike
>
>  
>
> *From:* Vittorio Bertocci <Vittorio=[e-mail]>
> *Sent:* Friday, October 15, 2021 4:19 PM
> *To:* Richard Backman, Annabelle <[e-mail]>
> *Cc:* Mike Jones <[e-mail]>; [e-mail]
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and
> OAuth 2.1
>
>  
>
> I am a fan of this approach. It feels pretty empty to cast people out
> of compliance just because they are handling a realistic circumstance,
> such as network failures, that we know about beforehand. 
>
> In addition, this gives us a chance to provide guidance on how to
> handle the situation, instead of leaving AS implementers to their own
> device.
>
>  
>
> On Fri, Oct 15, 2021 at 11:32 AM Richard Backman, Annabelle
> <richanna=[e-mail]
> <mailto:[e-mail]>> wrote:
>
>             The client MUST NOT use the authorization code more than once.
>
>      
>
>     This language makes it impossible to build a fault tolerant, spec
>     compliant client, as it prohibits retries. We could discuss
>     whether a retry really constitutes a separate "use", but
>     ultimately it doesn't matter; multiple presentations of the same
>     code look the same to the AS, whether they are the result of
>     retries, the client attempting to get multiple sets of tokens, or
>     an unauthorized party trying to replay the code.
>
>      
>
>     I think we can have a fault tolerant, replay-proof implementation,
>     but it takes some effort:
>
>      
>
>      1. The AS can prevent the authorized client from using one code
>         to get a bunch of independent refresh and access token pairs
>         by either re-issuing the same token (effectively making the
>         token request idempotent) or invalidating previously issued
>         tokens for that code. (Almost but not quite
>         idempotent…idempotent-adjacent?)
>      2. The AS can prevent unauthorized parties from replaying snooped
>         codes+PKCE by requiring stronger client authentication:
>         implement dynamic client registration and require a
>         replay-resistant client authentication method like
>         `jwt-bearer`. The AS can enforce one-time use of the client
>         credential token without breaking fault tolerance, as the
>         client can easily mint a new one for each retry to the token
>         endpoint.
>
>      
>
>     Yes, I know, this is way more complex than just a credential-less
>     public client doing PKCE. Perhaps we can have our cake and eat it
>     too with language like:
>
>      
>
>         The client MUST NOT use the authorization code more than once,
>         unless retrying a token request that failed for reasons beyond
>         the scope of this protocol. (e.g., network interruption,
>         server outage) Refer to [Fault Tolerant Replay Prevention] for
>         guidance.
>
>      
>
>     …where Fault Tolerant Replay Prevention is a subsection under
>     Security Considerations. I don't think this wording is quite
>     right, as the guidance is really going to be for the AS, not the
>     client, but hopefully it's enough to get the idea across.
>
>      
>
>     —
>
>     Annabelle Backman (she/her)
>
>     [e-mail] <mailto:[e-mail]>
>
>      
>
>      
>

-- 
https://danielfett.de