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

-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. >> >> >

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

e 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 *On > Behalf Of *Warren Parad > *Sent:* Friday 15 October 2021 09:25 > *To:* Pieter Kasselman > > *

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

for implementors as they weigh the risks. Reducing it to MAY risks > diluting it too much. > >   > > *From:*OAuth *On Behalf Of *Warren Parad > *Sent:* Friday 15 October 2021 09:25 > *To:* Pieter Kasselman > *Cc:* IETF oauth WG > *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: A

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

ormed decisions. From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf Of Ash Narayanan Sent: Friday 15 October 2021 01:51 To: Aaron Parecki mailto:aa...@parecki.com>> Cc: IETF oauth WG mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.

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

*On Behalf Of *Ash Narayanan > *Sent:* Friday 15 October 2021 01:51 > *To:* Aaron Parecki > *Cc:* IETF oauth WG > *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and > OAuth 2.1 > > > > You don't often get email from ashvinnara

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

sday 13 October 2021 22:06 To: Aaron Parecki mailto:aa...@parecki.com>> Cc: IETF oauth WG mailto:oauth@ietf.org>> 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

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

ning 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 *On Behalf Of *Sascha Preibis

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

sday 13 October 2021 22:06 > *To:* Aaron Parecki > *Cc:* IETF oauth WG > *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

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

Sent: Wednesday 13 October 2021 22:06 To: Aaron Parecki Cc: IETF oauth WG 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

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 con

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

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 avo

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

The argument is "let's not have a requirement that doesn't serve to increase security". If we can't think of a reason why it's necessary or some attack it prevents against, it's better to allow AS to decide, rather than forcing an unnecessary implementation detail. Warren Parad Founder, CTO Secur

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

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 th

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

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 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? > > W

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

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? Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Wed

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

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 aut

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

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 a