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=40auth0....@dmarc.ietf.org> > *Sent:* Friday, October 15, 2021 4:19 PM > *To:* Richard Backman, Annabelle <richa...@amazon.com> > *Cc:* Mike Jones <michael.jo...@microsoft.com>; oauth@ietf.org > *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=40amazon....@dmarc.ietf.org > <mailto:40amazon....@dmarc.ietf.org>> 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) > > richa...@amazon.com <mailto:richa...@amazon.com> > > > > > -- https://danielfett.de
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
