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

[Daniel Fett <[e-mail]>]

Am 16.10.21 um 03:22 schrieb Ash Narayanan:
> Fully support Annabelle's idea of idempotent tokens.
> 1. It makes sense (give me the same code/verifier, I'll give you back
> the same tokens).
> 2. It negates the possible attack vectors mentioned by  Daniel.

All I see is that it opens another channel for token exfiltration, for
example if an attacker can read the token request but not the response.
This would be quite a fundamental change.

-Daniel


> 3. It is easy to implement.
>
> Regarding Mike's comments...
>
>     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.
>
> This offers no additional security and creates a poor user experience.
> With idempotent tokens, there is no incentive for the attacker to
> replay than to just use the already generated tokens, which I assume
> the attacker would have access to given they have access to the
> code/verifier.
>
>     Let’s not use OAuth 2.1 as an opportunity to sanction behaviors
>     that we can’t distinguish from attacks.
>
> I would argue that we should also take the opportunity to make
> Oauth2.1 more meaningful/easier to implement, by reducing unnecessary
> requirements that offer no additional security.
>
> Daniel did also mention this bit, which I agree with:
>
>     And ideally, the code SHOULD also be invalidated if the PKCE
>     verifier does not match, not sure if that is in the current text
>     or not.
>
>  
>
>     On Sat, Oct 16, 2021 at 10:42 AM Mike Jones
>     <Michael.Jones=[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>     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.
>
>      
>
>     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]
>     <mailto:[e-mail]>>
>     *Sent:* Friday, October 15, 2021 4:19 PM
>     *To:* Richard Backman, Annabelle <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc:* Mike Jones <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[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]>
>
>          
>
>          
>
>
>
>             On Oct 15, 2021, at 8:27 AM, Mike Jones
>             <Michael.Jones=[e-mail]
>             <mailto:Michael.Jones=[e-mail]>> wrote:
>
>              
>
>             *CAUTION*: This email originated from outside of the
>             organization. Do not click links or open attachments
>             unless you can confirm the sender and know the content is
>             safe.
>
>              
>
>             I agree with Daniel.
>
>              
>
>             Also, while we’ve talked about server requirements, I
>             think it’s equally important that we retain this client
>             requirement:
>
>              
>
>                 The client MUST NOT use the authorization code more
>             than once.
>
>              
>
>                                                                      
>             -- Mike
>
>              
>
>             *From:* OAuth <[e-mail]
>             <mailto:[e-mail]>> *On Behalf Of *Daniel Fett
>             *Sent:* Friday, October 15, 2021 8:13 AM
>             *To:* [e-mail] <mailto:[e-mail]>
>             *Subject:* Re: [OAUTH-WG] Re: Authorization code reuse and
>             OAuth 2.1
>
>              
>
>             I don't think that a MAY is appropriate here.
>
>              
>
>             I wasn't in the call yesterday, so I hope I don't miss
>             anything here, but...
>
>              
>
>             Even with PKCE, the one-time use requirement of the code
>             is still important. First and foremost, if we allow
>             unlimited re-use of the same code, even just as an option,
>             we change the semantics of this artifact. I guess there
>             are many examples where this causes issues, but one would
>             be DPoP. It assumes that there is only one (successful)
>             token request and in that request, the token is bound to a
>             specific key. If there can be more than one successful
>             token request, all it takes is code_challenge and the code
>             sitting around somewhere in accessible memory and an XSS
>             attacker can exfiltrate them and use them on his own
>             device, binding the resulting token to an
>             attacker-controlled key. This is the attack outcome
>             against which we introduced the nonce in DPoP. (Probably
>             we should add this thought as a security consideration to
>             DPoP, but that is a different topic.) I guess we can come
>             up with many other mechanisms and mitigations that depend
>             on code being one-time use.
>
>              
>
>             The attack described also shows nicely that code replay
>             protection and PKCE serve similar purposes, but are not
>             the same thing.
>
>              
>
>             The Security BCP introduces a second layer of defense at
>             pretty much all the critical places in the protocol,
>             because practice shows that a single defense can break too
>             easily. For example, an attacker with read-only access to
>             the token request would be pretty bad without code replay
>             protections in place. Such attackers are considered in
>             FAPI. (Somebody capable of reading system logs at the
>             client or server, proxy logs at the client or server,
>             browser logs, etc.)
>
>              
>
>             Therefore, in my opinion, the code MUST be short-lived and
>             at least SHOULD, better MUST be one-time use.
>
>              
>
>             And ideally, the code SHOULD also be invalidated if the
>             PKCE verifier does not match, not sure if that is in the
>             current text or not.
>
>              
>
>             -Daniel
>
>              
>
>              
>
>              
>
>             Am 15.10.21 um 11:04 schrieb Pieter Kasselman:
>
>                 SHOULD is more likely to cause the right conversations
>                 to take place for implementors as they weigh the
>                 risks. Reducing it to MAY risks diluting it too much.
>
>                  
>
>                 *From:* OAuth <[e-mail]>
>                 <mailto:[e-mail]> *On Behalf Of *Warren
>                 Parad
>                 *Sent:* Friday 15 October 2021 09:25
>                 *To:* Pieter
>                 Kasselman <pieter.kasselman=[e-mail]>
>                 <mailto:pieter.kasselman=[e-mail]>
>                 *Cc:* IETF oauth WG <[e-mail]>
>                 <mailto:[e-mail]>
>                 *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization
>                 code reuse and OAuth 2.1
>
>                  
>
>                 I wouldn't be against lowering it to MAY but only if
>                 we stipulate a SHOULD on an expected lifetime of an
>                 authorization code. I think sending the message that
>                 these should be one time use except in exceptional
>                 circumstances.
>
>
>                 	
>
>                 *Warren Parad*
>
>                 Founder, CTO
>
>                 Secure your user data with IAM authorization as a
>                 service. Implement Authress
>                 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154740432%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6rSI2UvnakrWNh3qtBEgIMbRO8L9oXu8zGj4Fd128B8%3D&reserved=0>.
>
>                  
>
>                  
>
>                 On Fri, Oct 15, 2021 at 10:17 AM Pieter Kasselman
>                 <pieter.kasselman=[e-mail]
>                 <mailto:[e-mail]>> wrote:
>
>                     Any weakening of the requirement should include a
>                     clear outline of the risks to help implementors
>                     make informed decisions.
>
>                      
>
>                     *From:* OAuth <[e-mail]
>                     <mailto:[e-mail]>> *On Behalf
>                     Of *Ash Narayanan
>                     *Sent:* Friday 15 October 2021 01:51
>                     *To:* Aaron Parecki <[e-mail]
>                     <mailto:[e-mail]>>
>                     *Cc:* IETF oauth WG <[e-mail]
>                     <mailto:[e-mail]>>
>                     *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re:
>                     Authorization code reuse and OAuth 2.1
>
>                      
>
>
>                     	
>
>                     You don't often get email
>                     from [e-mail]
>                     <mailto:[e-mail]>. Learn why this
>                     is important
>                     <http://aka.ms/LearnAboutSenderIdentification>
>
>                     	
>
>                         Yes, as I said before, authorization servers
>                         are free to enforce one-time use of the
>                         authorization code even if there isn't a
>                         requirement to. The proposal is just to remove
>                         the *requirement* of authorization servers
>                         enforcing it.
>
>                      
>
>                     I agree, and therefore I think what it really
>                     ought to be is "MAY".
>
>                      
>
>                     Annabelle said:
>
>                         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.
>
>                      
>
>                     Couldn't agree more. Having experienced these
>                     exact use-cases, I can honestly say that denying
>                     users a smooth experience just to be compliant
>                     with the spec, which offers no additional security
>                     if PKCE is also being used, makes no sense.
>
>                     It is also more effort (from a repository layer
>                     perspective) to implement one-time use than do
>                     PKCE verification.
>
>                      
>
>                         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?
>
>                      
>
>                     I'd be interested in these use-cases as well (I
>                     can't think of any). 
>
>                      
>
>                     On Thu, Oct 14, 2021 at 8:36 AM Aaron Parecki
>                     <[e-mail] <mailto:[e-mail]>> wrote:
>
>                         Yes, as I said before, authorization servers
>                         are free to enforce one-time use of the
>                         authorization code even if there isn't a
>                         requirement to. The proposal is just to remove
>                         the *requirement* of authorization servers
>                         enforcing it. 
>
>                          
>
>                         I am okay with Mike's suggestion of changing
>                         the language to "SHOULD" to continue to point
>                         out the possibility of enforcing one-time
>                         authorization codes if desired.
>
>                          
>
>                          
>
>                          
>
>                         On Wed, Oct 13, 2021 at 2:15 PM Pieter
>                         Kasselman <[e-mail]
>                         <mailto:[e-mail]>> wrote:
>
>                             Log files can exist in lots of place
>                             (clients, servers, data lakes). The
>                             question is whether it is a valid
>                             assumption that an attacker cannot obtain
>                             an Authorization Code and a Code Verifier
>                             and present it a second time round.
>                             Limiting the validity period is one layer
>                             of defence, PKCE is another layer, one
>                             time use enforcement is another. Assuming
>                             breach and designing from a defence in
>                             depth perspective is a good practice, so
>                             why not give implementors options (and
>                             guidance) to add additional layers of
>                             defence to match their risk profiles?  
>
>                              
>
>                              
>
>                             *From:* OAuth <[e-mail]
>                             <mailto:[e-mail]>> *On
>                             Behalf Of *Sascha Preibisch
>                             *Sent:* Wednesday 13 October 2021 22:06
>                             *To:* Aaron Parecki <[e-mail]
>                             <mailto:[e-mail]>>
>                             *Cc:* IETF oauth WG <[e-mail]
>                             <mailto:[e-mail]>>
>                             *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re:
>                             Authorization code reuse and OAuth 2.1
>
>                              
>
>                             Ok, if the goal is to avoid
>                             unnecessary requirements I am suggesting
>                             to point out why MUST was changed to
>                             SHOULD. Otherwise developers will start to
>                             mix and match OAuth 2.0 and OAuth 2.1
>                             requirements as they see them fit their needs.
>
>                             In regards to encrypted values in PKCE,
>                             Aaron, I can also not confirm that as the
>                             general implementation.
>
>                              
>
>                             On Wed, 13 Oct 2021 at 13:56, Aaron
>                             Parecki <[e-mail]
>                             <mailto:[e-mail]>> wrote:
>
>                                 The PKCE spec actually says
>                                 "Typically, the "code_challenge" and
>                                 "code_challenge_method" values are
>                                 stored in encrypted form in the "code"
>                                 itself" which I feel like might be a
>                                 stretch to say that's typical, but
>                                 this scenario was clearly thought of
>                                 ahead of time. Doing that would enable
>                                 an AS to avoid storing server-side state.
>
>                                  
>
>                                 On Wed, Oct 13, 2021 at 1:50 PM Sascha
>                                 Preibisch <[e-mail]
>                                 <mailto:[e-mail]>> wrote:
>
>                                     If the challenge is based on
>                                     distributed authorization server
>                                     configurations, how would they
>                                     handle PKCE? I imagine that
>                                     managing the state for PKCE is not
>                                     less challenging than managing
>                                     authorization codes on the server
>                                     side, preventing reuse of them. 
>
>                                     With that in mind I am not sure if
>                                     I follow the given argument. I
>                                     would prefer to keep MUST as it is
>                                     today.
>
>                                      
>
>                                      
>
>                                     On Wed, 13 Oct 2021 at 13:37,
>                                     Aaron Parecki <[e-mail]
>                                     <mailto:[e-mail]>> wrote:
>
>                                         HTTPS, because if that's
>                                         broken then the rest of OAuth
>                                         falls apart too.
>
>                                          
>
>                                         On Wed, Oct 13, 2021 at 1:36
>                                         PM Warren Parad
>                                         <[e-mail]
>                                         <mailto:[e-mail]>> wrote:
>
>                                             I feel like I'm missing
>                                             something, what stops just
>                                             plain old network sniffing
>                                             and replying the whole
>                                             encrypted payload to the
>                                             AS and getting back a
>                                             valid token?
>
>
>                                             <image001.jpg>
>
>                                             	
>
>                                             *Warren Parad*
>
>                                             Founder, CTO
>
>                                             Secure your user data with
>                                             IAM authorization as a
>                                             service.
>                                             Implement Authress
>                                             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154750385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y86Gy8RiRIbIAW3So8hr4PxYsta1VWX1X7l%2FHzVbcvI%3D&reserved=0>.
>
>                                              
>
>                                              
>
>                                             On Wed, Oct 13, 2021 at
>                                             10:33 PM Aaron Parecki
>                                             <[e-mail]
>                                             <mailto:[e-mail]>>
>                                             wrote:
>
>                                                 Aside from the "plain"
>                                                 method, the PKCE code
>                                                 verifier never leaves
>                                                 the client until it's
>                                                 sent along with the
>                                                 authorization code in
>                                                 the POST request to
>                                                 the token endpoint.
>                                                 The only place it can
>                                                 leak at that point is
>                                                 if the authorization
>                                                 server itself leaks
>                                                 it. If you have things
>                                                 leaking from the
>                                                 authorization server
>                                                 log, you likely have
>                                                 much bigger problems
>                                                 than authorization
>                                                 code replays.
>
>                                                  
>
>                                                 Keep in mind that even
>                                                 with the proposed
>                                                 change to drop the
>                                                 requirement of
>                                                 authorization codes
>                                                 being one time use,
>                                                 authorization servers
>                                                 are free to enforce
>                                                 this still if they
>                                                 want. Authorization
>                                                 code lifetimes are
>                                                 still expected to be
>                                                 short lived as well.
>
>                                                  
>
>                                                 Aaron
>
>                                                  
>
>                                                  
>
>                                                 On Wed, Oct 13, 2021
>                                                 at 1:25 PM Pieter
>                                                 Kasselman
>                                                 <[e-mail]
>                                                 <mailto:[e-mail]>>
>                                                 wrote:
>
>                                                     Aaron, I was
>                                                     curious what
>                                                     prevents an
>                                                     attacker from
>                                                     presenting an
>                                                     Authorization Code
>                                                     and a PKCE Code
>                                                     Verifier for a
>                                                     second time if the
>                                                     one time use
>                                                     requirement is
>                                                     removed. Is there
>                                                     another
>                                                     countermeasure in 
>                                                     PKCE that would
>                                                     prevent it? For
>                                                     example, an
>                                                     attacker may
>                                                     obtain the
>                                                     Authorization Code
>                                                     and the Code
>                                                     Verifier from a
>                                                     log and replay it.  
>
>                                                      
>
>                                                     Cheers
>
>                                                      
>
>                                                     Pieter
>
>                                                      
>
>                                                     *From:* OAuth
>                                                     <[e-mail]
>                                                     <mailto:[e-mail]>> *On
>                                                     Behalf Of *Aaron
>                                                     Parecki
>                                                     *Sent:* Wednesday
>                                                     13 October 2021 18:40
>                                                     *To:* Warren Parad
>                                                     <wparad=[e-mail]
>                                                     <mailto:[e-mail]>>
>                                                     *Cc:* Mike Jones
>                                                     <Michael.Jones=[e-mail]
>                                                     <mailto:[e-mail]>>; [e-mail]
>                                                     <mailto:[e-mail]>
>                                                     *Subject:* [EXTERNAL]
>                                                     Re: [OAUTH-WG]
>                                                     Authorization code
>                                                     reuse and OAuth 2.1
>
>                                                      
>
>                                                     Warren, I didn't
>                                                     see you on the
>                                                     interim call, so
>                                                     you might be
>                                                     missing some context.
>
>                                                      
>
>                                                     The issue that was
>                                                     discussed is that
>                                                     using PKCE already
>                                                     provides all the
>                                                     security benefit
>                                                     that is gained by
>                                                     enforcing
>                                                     single-use
>                                                     authorization
>                                                     codes. Therefore,
>                                                     requiring that
>                                                     they are
>                                                     single-use isn't
>                                                     necessary as it
>                                                     doesn't provide
>                                                     any additional
>                                                     benefit.
>
>                                                      
>
>                                                     If anyone can
>                                                     think of a
>                                                     possible attack by
>                                                     allowing
>                                                     authorization
>                                                     codes to be reused
>                                                     *even with a valid
>                                                     PKCE code
>                                                     verifier* then
>                                                     that would warrant
>                                                     keeping this
>                                                     requirement.
>
>                                                      
>
>                                                     ---
>
>                                                     Aaron Parecki
>
>                                                      
>
>                                                      
>
>                                                     On Wed, Oct 13,
>                                                     2021 at 10:27 AM
>                                                     Warren Parad
>                                                     <wparad=[e-mail]
>                                                     <mailto:[e-mail]>>
>                                                     wrote:
>
>                                                         Isn't it
>                                                         better for it
>                                                         to be worded
>                                                         as we want it
>                                                         to be, with
>                                                         the
>                                                         implication
>                                                         being that of
>                                                         course it
>                                                         might be
>                                                         difficult to
>                                                         do that, but
>                                                         that AS devs
>                                                         will think
>                                                         long and hard
>                                                         about
>                                                         sometimes not
>                                                         denying the
>                                                         request? Even
>                                                         with MUST,
>                                                         some AS will
>                                                         still allow
>                                                         reuse of auth
>                                                         codes. Isn't
>                                                         that better
>                                                         than flat out
>                                                         saying: /sure,
>                                                         there's a
>                                                         valid reason/
>
>                                                          
>
>                                                         In other
>                                                         words, how do
>                                                         we think about
>                                                         RFCs? Do they
>                                                         exist to be
>                                                         followed to
>                                                         the letter or
>                                                         not at all? Or
>                                                         do they exist
>                                                         to stipulate
>                                                         this is the
>                                                         way, but
>                                                         acknowledge
>                                                         that not
>                                                         everyone will
>                                                         build a
>                                                         solution that
>                                                         holds them as law.
>
>                                                          
>
>                                                         Let's look
>                                                         at *SHOULD*
>
>                                                             This word,
>                                                             or the
>                                                             adjective
>                                                             "RECOMMENDED",
>                                                             mean that
>                                                             there may
>                                                             exist
>                                                             valid
>                                                             reasons in
>                                                             particular
>                                                             circumstances
>                                                             to ignore
>                                                             a
>                                                             particular
>                                                             item, but
>                                                             the full
>                                                             implications
>                                                             must be
>                                                             understood
>                                                             and
>                                                             carefully
>                                                             weighed
>                                                             before
>                                                             choosing a
>                                                             different
>                                                             course.
>
>                                                          
>
>                                                         I
>                                                         think /recommended/ here
>                                                         is not
>                                                         sufficient nor
>                                                         are there
>                                                         valid reasons.
>                                                         "It's too
>                                                         hard" isn't
>                                                         really a valid
>                                                         reason. Isn't
>                                                         it better in
>                                                         this case for
>                                                         an AS to not
>                                                         be compliant
>                                                         with the RFC,
>                                                         than it is to
>                                                         relax this to
>                                                         SHOULD and
>                                                         have lots of
>                                                         AS thinking
>                                                         reusing auth
>                                                         codes is a
>                                                         viable
>                                                         solution,
>                                                         "because they
>                                                         are a special
>                                                         snowflake
>                                                         where SHOULD
>                                                         should apply".
>
>                                                          
>
>                                                         Are we setting
>                                                         the standard
>                                                         or instead
>                                                         attempting to
>                                                         sustain a
>                                                         number of "AS
>                                                         that are in
>                                                         compliance
>                                                         with the RFC"?
>
>                                                          
>
>                                                         <image001.jpg>
>
>                                                         	
>
>                                                         *Warren Parad*
>
>                                                         Founder, CTO
>
>                                                         Secure your
>                                                         user data with
>                                                         IAM
>                                                         authorization
>                                                         as a service.
>                                                         Implement Authress
>                                                         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154760332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lbb9cJl0VUcfBD9IwzKF4BeB5nnggZxLB1TwlZYdNK4%3D&reserved=0>.
>
>                                                          
>
>                                                          
>
>                                                         On Wed, Oct
>                                                         13, 2021 at
>                                                         7:17 PM Mike
>                                                         Jones
>                                                         <Michael.Jones=[e-mail]
>                                                         <mailto:[e-mail]>>
>                                                         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
>                                                             [e-mail]
>                                                             <mailto:[e-mail]>
>                                                             https://www.ietf.org/mailman/listinfo/oauth
>                                                             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154760332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=u3yNDEeIsFvqGwu3x8%2F22D25o3bVO9PkrBEA2IEKSzY%3D&reserved=0>
>
>                                                         _______________________________________________
>                                                         OAuth mailing list
>                                                         [e-mail]
>                                                         <mailto:[e-mail]>
>                                                         https://www.ietf.org/mailman/listinfo/oauth
>                                                         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154770299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7JX5eYOgW7gjFIIySrFurb2%2B9dBhH4IAsXhIMkV%2FGps%3D&reserved=0>
>
>                                         _______________________________________________
>                                         OAuth mailing list
>                                         [e-mail]
>                                         <mailto:[e-mail]>
>                                         https://www.ietf.org/mailman/listinfo/oauth
>                                         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154770299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7JX5eYOgW7gjFIIySrFurb2%2B9dBhH4IAsXhIMkV%2FGps%3D&reserved=0>
>
>                         _______________________________________________
>                         OAuth mailing list
>                         [e-mail] <mailto:[e-mail]>
>                         https://www.ietf.org/mailman/listinfo/oauth
>                         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154780256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lJqE32wIC4OoFoYfUMYr8zd3pgEz2abBr2aga42rFsA%3D&reserved=0>
>
>                     _______________________________________________
>                     OAuth mailing list
>                     [e-mail] <mailto:[e-mail]>
>                     https://www.ietf.org/mailman/listinfo/oauth
>                     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154780256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lJqE32wIC4OoFoYfUMYr8zd3pgEz2abBr2aga42rFsA%3D&reserved=0>
>
>                  
>
>                 _______________________________________________
>
>                 OAuth mailing list
>
>                 [e-mail] <mailto:[e-mail]>
>
>                 https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
>              
>
>             -- 
>
>             https://danielfett.de <https://danielfett.de/>
>
>             _______________________________________________
>             OAuth mailing list
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/oauth
>             <https://www.ietf.org/mailman/listinfo/oauth>
>
>          
>
>         _______________________________________________
>         OAuth mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/oauth
>         <https://www.ietf.org/mailman/listinfo/oauth>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de