[OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B Authorization

[Aaron Parecki]

Yeah this just sounds like the client credentials grant with some policy at
the AS. There's no limitation that the client credentials grant is only
used to access resources owned by the client. From 6749:

   The client can request an access token using only its client
   credentials (or other supported means of authentication) when the
   client is requesting access to the protected resources under its
   control, or those of another resource owner that have been previously
   arranged with the authorization server (the method of which is beyond
   the scope of this specification).



On Sun, May 19, 2024 at 5:16 AM Igor Janicijevic  wrote:

> The idea is that the resource owner client can delegate some or all of its
> own scopes. For example, if the resource owner client can obtain “read” and
> “write” scopes on its own resource, it can decide to delegate “read” scope
> for that resource to the third party client, but not the “write” scope.
> This means that the third party client will only be able to obtain read
> only access to that resource and will not be able to update the resource.
>
>
>
> *From:* Warren Parad [mailto:wpa...@rhosys.ch]
> *Sent:* Sunday, 19 May 2024 9:57 PM
> *To:* Igor Janicijevic 
> *Cc:* Thomas Broyer ;   >
> *Subject:* Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B
> Authorization
>
>
>
> Hmmm, interesting. How does the first-party client decide which scopes to
> grant to the third party service?
>
>
>
> On Sun, May 19, 2024 at 1:52 PM Igor Janicijevic  wrote:
>
> Maybe I failed to set the context here, as you rightly pointed out. This
> new proposed flow is for B2B or system to system interactions only, i.e. no
> user agents (browsers) and no humans (end users) are involved, so there are
> no user agent redirects…
>
>
>
> In standard OAuth, for system to system access tokens are obtained using
> client_credentials grant type, where resource owner client authenticates to
> AS and obtains a token which it then uses to access its own resources held
> at resource server. No third party client is involved in this flow because
> this is direct access by resource owner to its own resources – there is no
> delegation and no “on behalf of access”…
>
>
>
> There is no delegated flow for system to system access in the standard
> OAuth, as far as I know…
>
>
>
>
>
> *From:* Warren Parad [mailto:wpa...@rhosys.ch]
> *Sent:* Sunday, 19 May 2024 9:18 PM
> *To:* Igor Janicijevic 
> *Cc:* Thomas Broyer ;   >
> *Subject:* Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B
> Authorization
>
>
>
> Maybe let's separate those two things for a second:
>
>1.  Third party acquiring token to access RS
>2.  RO revoking token generated for the Third Party client
>
>
>
> For #1. I'd be interested to know how this is any different from an OAuth
> Client that wants to access RS on behalf of the RO. In this case the
> "Client" would be the Third Party (TP). TP redirects user agent to AS to
> authorize token generation, then AS redirects user agent back to TP with
> auth_code/refresh token/etc.
>
>
>
> The token issued by AS to third party client is not presented to the
> resource owner client
>
>
>
> Correct, and isn't that the same as the standard OAuth flow? If not I
> think additional context there would be appreciated.
>
>
>
> - Warren
>
>
>
> On Sun, May 19, 2024 at 1:01 PM Igor Janicijevic  wrote:
>
> Hi Warren,
>
>
>
> There are four parties in this flow: the resource owner client, the third
> party client, the resource server and the AS. The token issued by AS to
> third party client is not presented to the resource owner client – it is
> only presented to the resource server when third party client is accessing
> the resources. This means that the resource owner client cannot revoke that
> token because it will have to have a possession of it to present it to the
> revocation endpoint… Maybe I am completely missing your point, so can you,
> please, clarify.
>
>
>
> Cheers,
>
> Igor
>
>
>
>
>
> *From:* Warren Parad [mailto:wpa...@rhosys.ch]
> *Sent:* Sunday, 19 May 2024 7:14 PM
> *To:* Igor Janicijevic 
> *Cc:* Thomas Broyer ;   >
> *Subject:* Re: [OAUTH-WG] Re: New Internet Draft: OAuth 2.0 Delegated B2B
> Authorization
>
>
>
> But the AS is already governing the access between clients, so at the
> surface at least I'm not able to wrap my head around your counterargument.
>
>
>
> Also this:
>
> Also, the resource owner client cannot easily revoke tokens issued to
> third party clients that it federates access with.
>
>
>
> Why not? It is just as easy to revoke a token issued to third party
> clients as it is to do in any OAuth compatible RS. What makes this case
> special for you, that the "Resource Owner" (your service client) in this
> case would not be able to revoke the tokens issued to the "Client" (the
> Third party application).
>
>
>
> Isn't this all doable with OAuth in spec without any magic?
>
>
>
> On Sun, May 19, 2024 at 10:28 AM Igor Janicijevic  

[OAUTH-WG] Re: Second WGLC for OAuth 2.0 Protected Resource Metadata

[Aaron Parecki]

As a co-author of the draft, I believe we've addressed all the first WGLC
comments and that this is ready for publication. Thanks!

Aaron

On Wed, May 15, 2024 at 9:05 AM Michael Jones 
wrote:

> Having addressed the first WGLC comments in -04 and adding a pretty
> diagram in -05, I believe this is ready for publication.
>
>
>
> Thanks,
>
> -- Mike
>
>
>
> *From:* Rifaat Shekh-Yusef 
> *Sent:* Wednesday, May 15, 2024 7:11 AM
> *To:* oauth 
> *Subject:* [OAUTH-WG] Second WGLC for OAuth 2.0 Protected Resource
> Metadata
>
>
>
> All,
>
> This is a *second* *WG Last Call* for the *OAuth 2.0 Protected Resource
> Metadata* document (the previous one was for v03.).
> https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-05.html
>
>
>
> Please, review this document and reply on the mailing list if you have any
> comments or concerns, by *May 29*.
>
> If you reviewed the document and you do not have any comments or concerns,
> it would be great if you can reply to this email indicating that.
>
> Regards,
>   Rifaat & Hannes
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: New draft: OAuth Profile for Open Public Clients

[Aaron Parecki]

Thanks for writing this up! I remember talking about this with you at a
past IETF meeting.

I agree this is a useful profile for this ecosystem. I would be happy to
help with this document, as well as help prepare a presentation on this at
the next IETF meeting.

---
Aaron Parecki



On Thu, May 16, 2024 at 8:56 PM Neil Jenkins  wrote:

> Hello all,
>
> I have published a draft document I'd like to introduce to the working
> group to consider: OAuth Profile for Open Public Clients
> <https://www.ietf.org/archive/id/draft-jenkins-oauth-public-00.html>.
>
> *Background*
>
> I work for Fastmail <https://www.fastmail.com/>, and we organised a
> conference at the end of last year with a bunch of the other major mailbox
> providers to work on interoperability and improving the open ecosystem. The
> topic most on everyone's minds was authentication.
>
> Unlike all the walled garden messaging systems, email remains to a large
> extent open. There are standard protocols (IMAP [RFC9051]
> <https://www.rfc-editor.org/rfc/rfc9051.html>, SMTP [RFC5321]
> <https://datatracker.ietf.org/doc/html/rfc5321>, and more recently JMAP
> [RFC8620] <https://datatracker.ietf.org/doc/html/rfc8620>[RFC8621]
> <https://datatracker.ietf.org/doc/html/rfc8621>) so you can have clients
> and servers built by different vendors, with no pre-existing relationship.
> Indeed, there are probably thousands of clients, and hundreds of thousands
> of servers out there. The situation is similar with contacts and calendars.
>
> Most server providers (and indeed many client authors) would like to move
> to a more secure authentication system, but at the moment basic auth is the
> only interoperable mechanism. Many clients have hardcoded Gmail/Microsoft
> OAuth flows (as those companies are big enough to force them to do so!),
> but this does not scale. At the conference we worked on building an OAuth
> profile that we believe can significantly increase security compared to the
> current status quo, to allow native Email/Contacts/Calendar clients to
> authenticate with an arbitrary server.
>
> I have talked to a few of you individually at the last couple of IETF
> meetings, and have finally had time to write up our proposal.
>
> *Next steps*
>
> First of all, hopefully the working group can agree that this is a problem
> space that is significant, and worth addressing. If so, I hope it chooses
> to adopt this document as  a good starting point. I am not sure whether
> this should be a BCP rather than Standards Track — it deliberately does not
> introduce anything new, just combines a lot of existing standards in a
> specific way suitable for this use case.
>
> I will not be in Vancouver in person, but will join remotely. I do plan to
> be in Dublin. My current understanding is there are vendors such as Apple
> looking to start implementing something in this space in the nearish
> future, and obviously we would all like an agreed profile to ensure
> interoperability! They may be able to send someone to Vancouver.
>
> I would be very happy to bring on a co-author (or indeed largely pass it
> over to them, as I am very busy with other work at the moment, hence the
> delay in getting this draft together). I will certainly remain involved in
> any discussions around this area of course.
>
> I look forward to your feedback.
>
> Cheers,
> Neil.
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: I-D Action: draft-ietf-oauth-v2-1-11.txt

[Aaron Parecki]

Hi all,

Thanks for the productive discussion at the interim meeting today. I've
taken the feedback and published a new version with all the changes
discussed.

https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-11.html

Please review the diff here:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-v2-1-11

As mentioned on the call, there are still more issues to discuss. Please
feel free to chime in on the github issues!
https://github.com/oauth-wg/oauth-v2-1/issues

Aaron

On Tue, May 14, 2024 at 5:14 PM  wrote:

> Internet-Draft draft-ietf-oauth-v2-1-11.txt is now available. It is a work
> item of the Web Authorization Protocol (OAUTH) WG of the IETF.
>
>Title:   The OAuth 2.1 Authorization Framework
>Authors: Dick Hardt
>     Aaron Parecki
> Torsten Lodderstedt
>Name:draft-ietf-oauth-v2-1-11.txt
>Pages:   96
>Dates:   2024-05-14
>
> Abstract:
>
>The OAuth 2.1 authorization framework enables an application to
>obtain limited access to a protected resource, either on behalf of a
>resource owner by orchestrating an approval interaction between the
>resource owner and an authorization service, or by allowing the
>application to obtain access on its own behalf.  This specification
>replaces and obsoletes the OAuth 2.0 Authorization Framework
>described in RFC 6749 and the Bearer Token Usage in RFC 6750.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-11.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-v2-1-11
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: WGLC for Browser-Based Apps

[Aaron Parecki]

Apologies for not noticing that earlier! I've just corrected the spelling
and updated the DPoP references in the editor's draft on GitHub. I will
hold off on publishing a new version to datatracker until there are other
more substantial changes. Not that the spelling of your name is
unsubstantial...

Aaron

On Mon, May 6, 2024 at 11:15 AM Brian Campbell  wrote:

> I just glanced through the draft looking for my name (everyone does that,
> right?) and noticed my surname misspelled in a couple of the references 
> (Cambpell
> should be Campbell).
>
> Might I kindly ask the document editors, one of whom has been my co-worker
> for 20+ years, to correct this? And probably update at least one of the
> associated references as well (DPoP is now RFC 9449).
>
> Thank you for you time and attention to this important matter,
> Brian "not Cambpell" Campbell
>
>
>
> On Wed, May 1, 2024 at 11:43 AM Aaron Parecki  40parecki@dmarc.ietf.org> wrote:
>
>> Thanks Rifaat,
>>
>> The editors have just published draft -18 addressing the comments from
>> Justin Richer's and Andy Barlow's reviews.
>>
>>
>> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-18.html
>>
>> Aaron
>>
>>
>> On Wed, May 1, 2024 at 5:51 AM Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com> wrote:
>>
>>> All,
>>>
>>> This is a *WG Last Call* for the *Browser-Based Apps* draft.
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/
>>>
>>> Please, review this document and reply on the mailing list if you have
>>> any comments or concerns, by *May 15. *
>>> If you reviewed the document and you do not have any comments or
>>> concerns, it would be great if you can reply to this email indicating that.
>>>
>>> Regards,
>>>   Rifaat & Hannes
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-metadata-05.txt

[Aaron Parecki]

Hi all, in preparation for WGLC, I added an SVG version of the flow diagram
to the HTML version of the draft, but no other changes were made. Thanks!

---
Aaron Parecki



On Fri, May 3, 2024 at 4:38 PM  wrote:

> Internet-Draft draft-ietf-oauth-resource-metadata-05.txt is now available.
> It
> is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF.
>
>Title:   OAuth 2.0 Protected Resource Metadata
>Authors: Michael B. Jones
> Phil Hunt
>     Aaron Parecki
>Name:draft-ietf-oauth-resource-metadata-05.txt
>Pages:   25
>Dates:   2024-05-03
>
> Abstract:
>
>This specification defines a metadata format that an OAuth 2.0 client
>or authorization server can use to obtain the information needed to
>interact with an OAuth 2.0 protected resource.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/
>
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-metadata-05
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-resource-metadata-05
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC for Browser-Based Apps

[Aaron Parecki]

Thanks Rifaat,

The editors have just published draft -18 addressing the comments from
Justin Richer's and Andy Barlow's reviews.

https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-18.html

Aaron


On Wed, May 1, 2024 at 5:51 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is a *WG Last Call* for the *Browser-Based Apps* draft.
> https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/
>
> Please, review this document and reply on the mailing list if you have any
> comments or concerns, by *May 15. *
> If you reviewed the document and you do not have any comments or concerns,
> it would be great if you can reply to this email indicating that.
>
> Regards,
>   Rifaat & Hannes
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7823)

[Aaron Parecki]

I'm not sure where the mismatch is happening then, because there is no
requirement that scopes are limited to certain clients at least from the
perspective of the specification. If the authorization server has a policy
that only "Client A" can request "scope_a", and then it allows "Client B"
to request that scope, that sounds like a problem with that authorization
server implementation. However this would be allowed according to RFC6749.

I did find this text you might be able to point to that makes this clearer:

https://datatracker.ietf.org/doc/html/rfc6749#section-4.4.1

> Since the client authentication is used as the authorization grant,
> no additional authorization request is needed.

The key being that the client authentication (mTLS in your example) IS the
authorization grant, so should be used to make authorization decisions.

Aaron


On Mon, Feb 26, 2024 at 3:37 PM Alexander Stumpf  wrote:

> Thanks for the quick reply and I understand your rationale.
>
> Maybe I rephrase the issue we are having right now:
>
> The authorization server should use the identity of the client (proven by
> authentication) to come to a conclusion whether or not the client is
> authorized to receive the access token. While this sounds trivial and
> obvious, it is not explicitely stated in the RFC (please correct me if I am
> wrong), and therefore $VENDOR exist that claims that they are in accordance
> with the RFC when they
>
> 1) receive the identity of the client through a valid and trusted client
> certificate ("authentication" via mTLS)
>
> 2) issue the access token to the client according to the demanded scope,
> ignoring the identity from 1)
>
> I thought proving them wrong by finding the respective section in the RFC
> would be easy, but I did not find any statement to support my view.
>
>
>
> Am 2024-02-27 00:19, schrieb Aaron Parecki:
>
> This errata should be rejected.
>
> The client credentials grant results in an access token issued to
> the client that presented credentials. There is no mechanism for "Client A"
> to request a token for "Client B" using the client credentials grant, since
> the credentials themselves are what determines which client the token is
> issued to. However, this access token is not "bound" to the client, since
> it is still a bearer token. (Other extensions like DPoP can add a binding
> of the access token to the client.)
>
> Aaron
>
>
> On Mon, Feb 26, 2024 at 3:14 PM RFC Errata System <
> rfc-edi...@rfc-editor.org> wrote:
>
> The following errata report has been submitted for RFC6749,
> "The OAuth 2.0 Authorization Framework".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7823
>
> --
> Type: Editorial
> Reported by: Alexander Stumpf 
>
> Section: 3.2.1
>
> Original Text
> -
>Confidential clients or other clients issued client credentials MUST
>authenticate with the authorization server as described in
>Section 2.3 when making requests to the token endpoint.  Client
>authentication is used for:
>
>o  Enforcing the binding of refresh tokens and authorization codes to
>   the client they were issued to.  Client authentication is critical
>   when an authorization code is transmitted to the redirection
>   endpoint over an insecure channel or when the redirection URI has
>   not been registered in full.
>
> Corrected Text
> --
>Confidential clients or other clients issued client credentials MUST
>authenticate with the authorization server as described in
>Section 2.3 when making requests to the token endpoint.  Client
>authentication is used for:
>
>o  Enforcing the binding of refresh tokens, authorization codes, and
>   (in the case of the Client Credentials Grant as described in
>   Section 4.4) the access token to the client they were issued to.
>   Client authentication is critical when an authorization code is
>   transmitted to the redirection endpoint over an insecure channel
>   or when the redirection URI has not been registered in full.
>
> Notes
> -
> Section 4.4.2 requires for the "client_credentials" grant type that the
> client is authenticated to the authorization server according to section
> 3.2.1. The reason for this authentication is (or so I assume) that the
> to-be-issued access token shall be bound to the correct (authenticated)
> client. Otherwise, the client could authenticate with valid credentials as
> "client A" and request a token for "client B", and wou

Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7823)

[Aaron Parecki]

This errata should be rejected.

The client credentials grant results in an access token issued to
the client that presented credentials. There is no mechanism for "Client A"
to request a token for "Client B" using the client credentials grant, since
the credentials themselves are what determines which client the token is
issued to. However, this access token is not "bound" to the client, since
it is still a bearer token. (Other extensions like DPoP can add a binding
of the access token to the client.)

Aaron


On Mon, Feb 26, 2024 at 3:14 PM RFC Errata System 
wrote:

> The following errata report has been submitted for RFC6749,
> "The OAuth 2.0 Authorization Framework".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7823
>
> --
> Type: Editorial
> Reported by: Alexander Stumpf 
>
> Section: 3.2.1
>
> Original Text
> -
>Confidential clients or other clients issued client credentials MUST
>authenticate with the authorization server as described in
>Section 2.3 when making requests to the token endpoint.  Client
>authentication is used for:
>
>o  Enforcing the binding of refresh tokens and authorization codes to
>   the client they were issued to.  Client authentication is critical
>   when an authorization code is transmitted to the redirection
>   endpoint over an insecure channel or when the redirection URI has
>   not been registered in full.
>
> Corrected Text
> --
>Confidential clients or other clients issued client credentials MUST
>authenticate with the authorization server as described in
>Section 2.3 when making requests to the token endpoint.  Client
>authentication is used for:
>
>o  Enforcing the binding of refresh tokens, authorization codes, and
>   (in the case of the Client Credentials Grant as described in
>   Section 4.4) the access token to the client they were issued to.
>   Client authentication is critical when an authorization code is
>   transmitted to the redirection endpoint over an insecure channel
>   or when the redirection URI has not been registered in full.
>
> Notes
> -
> Section 4.4.2 requires for the "client_credentials" grant type that the
> client is authenticated to the authorization server according to section
> 3.2.1. The reason for this authentication is (or so I assume) that the
> to-be-issued access token shall be bound to the correct (authenticated)
> client. Otherwise, the client could authenticate with valid credentials as
> "client A" and request a token for "client B", and would still be in
> accordance with the RFC, which is probably not intended.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --
> RFC6749 (draft-ietf-oauth-v2-31)
> --
> Title   : The OAuth 2.0 Authorization Framework
> Publication Date: October 2012
> Author(s)   : D. Hardt, Ed.
> Category: PROPOSED STANDARD
> Source  : Web Authorization Protocol
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-16.txt

[Aaron Parecki]

Hi all,

Thanks to Filip Skokan for his thorough review of the OAuth for
Browser-Based Apps BCP. I've incorporated his changes as well as a few
other editorial fixes from Louis Jannett and published Draft 16. You can
view the latest version here:

https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-16.html

Aaron


On Fri, Feb 16, 2024 at 4:24 PM  wrote:

> Internet-Draft draft-ietf-oauth-browser-based-apps-16.txt is now
> available. It
> is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF.
>
>Title:   OAuth 2.0 for Browser-Based Apps
>    Authors: Aaron Parecki
> David Waite
> Philippe De Ryck
>Name:draft-ietf-oauth-browser-based-apps-16.txt
>Pages:   59
>Dates:   2024-02-16
>
> Abstract:
>
>This specification details the threats, attack consequences, security
>considerations and best practices that must be taken into account
>when developing browser-based applications that use OAuth 2.0.
>
> Discussion Venues
>
>This note is to be removed before publishing as an RFC.
>
>Discussion of this document takes place on the Web Authorization
>Protocol Working Group mailing list (oauth@ietf.org), which is
>archived at https://mailarchive.ietf.org/arch/browse/oauth/.
>
>Source for this draft and an issue tracker can be found at
>https://github.com/oauth-wg/oauth-browser-based-apps.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-16.html
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-browser-based-apps-16
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth browser based apps with first-party same-domain apps

[Aaron Parecki]

oked as well (ATs contain
> authentication context identifier and Token introspection checks for
> revocation).
>
>
>
> Should there be no valid login session (cookie) or should the token
> request demand a step-up authentication, the AS will respond with a
> respective error to let the client know that user interaction is required,
> in which case the client will initiate a standard Authcode grant to allow
> user-interaction (re-auth, fulfill obligations). Optionally, the AS can use
> a secondary device to interact with the End-User (e.g. get consent or raise
> level of assurance of the login session) whilst holding back the token
> response or telling the client to resend the token request after a specific
> time so that user interaction can complete on the second device.
>
>
>
> The shortcut by directly calling the Token endpoint has a few advantages:
>
>
>
>- No iframe with redirect which might end up in a failure not
>captured. Also no redirect_uri necessary.
>- No need for PKCE and state
>- Just one request to obtain the Token(s)
>
>
>
> I hope to get your feedback about this.
>
>
>
> Thanks,
>
> Kai
>
>
>
> *From: *OAuth  on behalf of Aaron Parecki  40parecki@dmarc.ietf.org>
> *Date: *Monday, 23. October 2023 at 18:22
> *To: *"oauth@ietf.org" 
> *Subject: *Re: [OAUTH-WG] I-D Action:
> draft-ietf-oauth-browser-based-apps-15.txt
>
>
>
> After a lot of discussion on the mailing list over the last few months,
> and after some excellent discussions at the OAuth Security Workshop, we've
> been working on revising the draft to provide clearer guidance and clearer
> discussion of the threats and consequences of the various architectural
> patterns in the draft.
>
> I would like to give a huge thanks to Philippe De Ryck for stepping up to
> work on this draft as a co-author!
>
> This version is a huge restructuring of the draft and now starts with a
> concrete description of possible threats of malicious JavaScript as well as
> the consequences of each. The architectural patterns have been updated to
> reference which of each threat is mitigated by the pattern. This
> restructuring should help readers make a better informed decision by being
> able to evaluate the risks and benefits of each solution.
>
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps
>
>
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html
>
> Please give this a read, I am confident that this is a major improvement
> to the draft!
>
>
>
> Aaron
>
>
>
> On Mon, Oct 23, 2023 at 8:35 AM  wrote:
>
> Internet-Draft draft-ietf-oauth-browser-based-apps-15.txt is now
> available. It
> is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF.
>
>Title:   OAuth 2.0 for Browser-Based Apps
>Authors: Aaron Parecki
> David Waite
> Philippe De Ryck
>Name:draft-ietf-oauth-browser-based-apps-15.txt
>Pages:   58
>Dates:   2023-10-23
>
> Abstract:
>
>This specification details the threats, attack consequences, security
>considerations and best practices that must be taken into account
>when developing browser-based applications that use OAuth 2.0.
>
> Discussion Venues
>
>This note is to be removed before publishing as an RFC.
>
>Discussion of this document takes place on the Web Authorization
>Protocol Working Group mailing list (oauth@ietf.org), which is
>archived at https://mailarchive.ietf.org/arch/browse/oauth/.
>
>Source for this draft and an issue tracker can be found at
>https://github.com/oauth-wg/oauth-browser-based-apps.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-browser-based-apps-15
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Weekly github digest (OAuth Activity Summary)

[Aaron Parecki]

Happy Monday! I just added several OAuth GitHub repos to the IETF tools
that send out this weekly digest about activity on GitHub. I hope this
helps everyone become more aware of the activity in the group. If you have
an adopted draft on GitHub that isn't part of this list, get in touch with
me and we can get it added too. Thanks!

Aaron


On Sat, Feb 3, 2024 at 11:40 PM Repository Activity Summary Bot
 wrote:

> Sunday February 04, 2024
>
> Events without label "editorial"
> Issues oauth-wg/oauth-identity-chaining (+0/-4/5)
>
> 5 issues received 5 new comments:
>
>- #69 Add Aaron Parecki to acknowledgements section
><https://github.com/oauth-wg/oauth-identity-chaining/issues/69> (1 by
>bc-pi)
>- #67 Change spec name to focus on Authz
><https://github.com/oauth-wg/oauth-identity-chaining/issues/67> (1 by
>bc-pi)
>- #61 authorization grant type can't be the same as the issued token
>type <https://github.com/oauth-wg/oauth-identity-chaining/issues/61>
>(1 by bc-pi)
>- #60 example response missing issued_token_type
><https://github.com/oauth-wg/oauth-identity-chaining/issues/60> (1 by
>bc-pi)
>- #45 Consider limiting token formats to JWT
><https://github.com/oauth-wg/oauth-identity-chaining/issues/45> (1 by
>bc-pi)
>
> 4 issues closed:
>
>- #69 Add Aaron Parecki to acknowledgements section
><https://github.com/oauth-wg/oauth-identity-chaining/issues/69>
>- #61 authorization grant type can't be the same as the issued token
>type <https://github.com/oauth-wg/oauth-identity-chaining/issues/61>
>- #60 example response missing issued_token_type
><https://github.com/oauth-wg/oauth-identity-chaining/issues/60>
>- #45 Consider limiting token formats to JWT
><https://github.com/oauth-wg/oauth-identity-chaining/issues/45>
>
> oauth-wg/oauth-transaction-tokens (+2/-11/22)
>
> 2 issues created:
>
>- #69 Do we still need replacement transaction tokens.
><https://github.com/oauth-wg/oauth-transaction-tokens/issues/69> (by
>PieterKas)
>- #66 Trust domain/audience claim format URI or StringOrUri?
><https://github.com/oauth-wg/oauth-transaction-tokens/issues/66> (by
>obfuscoder)
>
> 9 issues received 22 new comments:
>
>- #69 Do we still need replacement transaction tokens.
><https://github.com/oauth-wg/oauth-transaction-tokens/issues/69> (1 by
>PieterKas)
>- #63 audience REQUIRED for just one trust domain?
><https://github.com/oauth-wg/oauth-transaction-tokens/issues/63> (4 by
>gffletch, obfuscoder, tulshi)
>- #62 Long-living Access Token needed for internal batch
>processes/offline tasks?
><https://github.com/oauth-wg/oauth-transaction-tokens/issues/62> (4 by
>gffletch, obfuscoder, tulshi)
>- #58 Authorization details presentation and processing
><https://github.com/oauth-wg/oauth-transaction-tokens/issues/58> (1 by
>tulshi) PR57
>- #56 RFC 9493 and sub_id formats
><https://github.com/oauth-wg/oauth-transaction-tokens/issues/56> (3 by
>obfuscoder, tulshi) PR57
>- #53 Transaction Tokens for S2S calls
><https://github.com/oauth-wg/oauth-transaction-tokens/issues/53> (5 by
>dteleguin, obfuscoder, tulshi)
>- #52 Should the azd claim be mandatory or optional
><https://github.com/oauth-wg/oauth-transaction-tokens/issues/52> (1 by
>tulshi) pre-adoption
>- #35 How do internal services authorize the Transaction Tokens?
><https://github.com/oauth-wg/oauth-transaction-tokens/issues/35> (2 by
>obfuscoder, tulshi)
>- #21 Txt token Header
><https://github.com/oauth-wg/oauth-transaction-tokens/issues/21> (1 by
>obfuscoder)
>
> 11 issues closed:
>
>- #66 Trust domain/audience claim format URI or StringOrUri?
><https://github.com/oauth-wg/oauth-transaction-tokens/issues/66>
>- #63 audience REQUIRED for just one trust domain?
><https://github.com/oauth-wg/oauth-transaction-tokens/issues/63>
>- #48 "sender constrained" language needs improvement
><https://github.com/oauth-wg/oauth-transaction-tokens/issues/48>
>- #21 Txt token Header
><https://github.com/oauth-wg/oauth-transaction-tokens/issues/21>
>- #35 How do internal services authorize the Transaction Tokens?
><https://github.com/oauth-wg/oauth-transaction-tokens/issues/35>
>- #56 RFC 9493 and sub_id formats
><https://github.com/oauth-wg/oauth-transaction-tokens/issues/56> PR57
>- #52 Should the azd claim be mandatory or optional
><https://github.com/oauth-wg/

[OAUTH-WG] Potential for an OAuth POST-Initiated Framework

[Aaron Parecki]

Hi all,

As discussed at IETF 118 during the "First-Party Apps" session, there was
some interest in genericizing the idea of starting an OAuth flow with a
POST request, which could be used by this draft and would look similar
to PAR. This would essentially define a common way to start an OAuth
authorization request with a client-initiated POST request, but would
enable further types of uses beyond the single request_uri response defined
by PAR.

The framework would define:

• request_type = {extension-defined}
• Sending the authorization request parameters in the request body (with
similar language as used by PAR
https://datatracker.ietf.org/doc/html/rfc9126#name-request)
• How to layer on client authentication, attestation, etc
• The response of the request would be defined by extensions

It would also establish a registry of request types, input parameters and
response body values.

We would then rewrite the First-Party Apps draft as an extension of this
framework.

Before I go to write this up, I wanted to check if anyone has other
concrete extensions they might want to define? If there is at least one,
then it's worth it to me, but if this first-party apps would be the only
one for the foreseeable future then I'd like to continue working on the
draft as is.

So please let me know if you have anything in mind that could leverage
client-initiated POST requests. Thanks!

---
Aaron Parecki
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7715)

[Aaron Parecki]

This errata should be rejected, as section 4.2.2.1 is about the implicit
flow, which returns parameters in the fragment part of the URL, not query
parameters.


On Wed, Nov 29, 2023 at 11:51 AM RFC Errata System <
rfc-edi...@rfc-editor.org> wrote:

> The following errata report has been submitted for RFC6749,
> "The OAuth 2.0 Authorization Framework".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7715
>
> --
> Type: Editorial
> Reported by: Alex Wilson 
>
> Section: 4.2.2.1
>
> Original Text
> -
>
>HTTP/1.1 302 Found
>Location: https://client.example.com/cb#error=access_denied=xyz
>
> Corrected Text
> --
>
>HTTP/1.1 302 Found
>Location: https://client.example.com/cb?error=access_denied=xyz
>
> Notes
> -
> For query parameters, the hash should be a question mark.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --
> RFC6749 (draft-ietf-oauth-v2-31)
> --
> Title   : The OAuth 2.0 Authorization Framework
> Publication Date: October 2012
> Author(s)   : D. Hardt, Ed.
> Category: PROPOSED STANDARD
> Source  : Web Authorization Protocol
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Identity Chaining

[Aaron Parecki]

I support adoption. The draft lays out an application of several existing
OAuth building blocks. I have some additional use cases for the pattern
that are not yet mentioned in the draft and am planning on discussing them
with the authors.

Aaron


On Tue, Nov 14, 2023 at 4:59 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is an *official* call for adoption for the *Identity Chaining *draft:
>
> https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/
>
> Please, reply on the mailing list and let us know if you are in favor or
> against adopting this draft as WG document, by *Nov 28th.*
>
> Regards,
>  Rifaat & Hannes
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Aaron Parecki]

I don't think it's necessary to say "do the right things with cookies" in
the Security BCP. The Browser Apps BCP has a much deeper discussion of how
different browser-based architectures work with cookies so that seems like
a better place to actually have a real discussion about it.

Also +1 to what Daniel said about not continuing to add little things. Plus
I think it's too late anyway, publication has already been requested for
the Security BCP.

Aaron

On Sun, Nov 5, 2023 at 11:14 AM Daniel Fett  wrote:

> I agree with Aaron!
>
> Also we should be very careful about any additions to the Security BCP at
> this point. It is very easy to re-start the "one more thing" loop we've
> been stuck in for the last years. There may be more useful things to say,
> but we should put them on the list for a future second version of the BCP.
>
> -Daniel
> Am 05.11.23 um 20:03 schrieb Aaron Parecki:
>
> I don't think the Security BCP should incorporate cookie best practices
> directly in the document. If anything, it sounds like possibly a candidate
> for inclusion in the Browser Apps BCP.
>
> There are already some mentions of these cookie properties mentioned in
> the Browser Apps BCP, though only in reference to specific architectures,
> not as a general best practice. For example:
>
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security
>
> Aaron
>
> On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt  wrote:
>
>> Hey
>>
>> I was reviewing security on some sites I managed and checked to see if
>> the recommendations were in the BCP.
>>
>> I don't see anything around cookies such as httpOnly, sameSite, secure.
>>
>> I saw some HTTP security header suggestions buried in 4.16
>> (X-Frame-Options, CSP), but not for Strict-Transport-Security,
>> Permissions-Policy, or X-Content-Type-Options, and the CSP guidance is
>> rather vague.
>>
>> I understand these are general web security best practices, and perhaps I
>> missed it, but I think it would be useful to call out that best security
>> practices around cookies and headers should also be followed in Section 2,
>> and either have the best practices included, or direct the reader where to
>> find them.
>>
>> /Dick
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Aaron Parecki]

I don't think the Security BCP should incorporate cookie best practices
directly in the document. If anything, it sounds like possibly a candidate
for inclusion in the Browser Apps BCP.

There are already some mentions of these cookie properties mentioned in the
Browser Apps BCP, though only in reference to specific architectures, not
as a general best practice. For example:

https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security

Aaron

On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt  wrote:

> Hey
>
> I was reviewing security on some sites I managed and checked to see if the
> recommendations were in the BCP.
>
> I don't see anything around cookies such as httpOnly, sameSite, secure.
>
> I saw some HTTP security header suggestions buried in 4.16
> (X-Frame-Options, CSP), but not for Strict-Transport-Security,
> Permissions-Policy, or X-Content-Type-Options, and the CSP guidance is
> rather vague.
>
> I understand these are general web security best practices, and perhaps I
> missed it, but I think it would be useful to call out that best security
> practices around cookies and headers should also be followed in Section 2,
> and either have the best practices included, or direct the reader where to
> find them.
>
> /Dick
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-15.txt

[Aaron Parecki]

After a lot of discussion on the mailing list over the last few months, and
after some excellent discussions at the OAuth Security Workshop, we've been
working on revising the draft to provide clearer guidance and clearer
discussion of the threats and consequences of the various architectural
patterns in the draft.

I would like to give a huge thanks to Philippe De Ryck for stepping up to
work on this draft as a co-author!

This version is a huge restructuring of the draft and now starts with a
concrete description of possible threats of malicious JavaScript as well as
the consequences of each. The architectural patterns have been updated to
reference which of each threat is mitigated by the pattern. This
restructuring should help readers make a better informed decision by being
able to evaluate the risks and benefits of each solution.

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps

https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html

Please give this a read, I am confident that this is a major improvement to
the draft!

Aaron

On Mon, Oct 23, 2023 at 8:35 AM  wrote:

> Internet-Draft draft-ietf-oauth-browser-based-apps-15.txt is now
> available. It
> is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF.
>
>Title:   OAuth 2.0 for Browser-Based Apps
>    Authors: Aaron Parecki
> David Waite
> Philippe De Ryck
>Name:draft-ietf-oauth-browser-based-apps-15.txt
>Pages:   58
>Dates:   2023-10-23
>
> Abstract:
>
>This specification details the threats, attack consequences, security
>considerations and best practices that must be taken into account
>when developing browser-based applications that use OAuth 2.0.
>
> Discussion Venues
>
>This note is to be removed before publishing as an RFC.
>
>Discussion of this document takes place on the Web Authorization
>Protocol Working Group mailing list (oauth@ietf.org), which is
>archived at https://mailarchive.ietf.org/arch/browse/oauth/.
>
>Source for this draft and an issue tracker can be found at
>https://github.com/oauth-wg/oauth-browser-based-apps.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-browser-based-apps-15
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List

[Aaron Parecki]

Tobias, Paul, Christian,

I just noticed the new working group adopted version of this draft:
https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/

I posted this comment on Github, but I'll repeat it here for others. I find
the new name "OAuth Status List" confusing. While I understand wanting to
remove "JWT" and "CWT" from the name, I was not aware of that discussion
during the call for adoption. I would suggest renaming this to "OAuth Token
Status List" instead.

I also noticed you didn't mark it as replacing the individual draft in
datatracker. You can email supp...@ietf.org and request that they mark it
as replacing
https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ so
that the history tracks better.

I also noticed that there are significant changes to the draft between the
individual and working group versions. Typically it is better to post a
verbatim copy of the individual draft as the adopted version, and then make
changes in a -01 version.

Thanks!

Aaron



On Sat, Oct 14, 2023 at 5:56 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> Based on the feedback to this call for adoption, we declare this document
> adopted as a WG document.
>
>
> Authors,
>
> Please, submit this as a working group document at your earliest
> convenience.
>
> Regards,
>  Rifaat & Hannes
>
>
>
>
>
>
> On Tue, Oct 3, 2023 at 8:51 PM John Bradley  wrote:
>
>> +1 for adoption
>>
>> On Sat, Sep 30, 2023, 9:53 AM Rifaat Shekh-Yusef 
>> wrote:
>>
>>> All,
>>>
>>> This is an official call for adoption for the *JWT and CWT Status List*
>>> draft:
>>> https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/
>>>
>>> Please, reply *on the mailing list *and let us know if you are in *favor
>>> *or* against *adopting this draft as WG document, by *Oct 13th*.
>>>
>>> Regards,
>>>  Rifaat & Hannes
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Updated "OAuth for First-Party Apps" draft

[Aaron Parecki]

Hi all,

The authors have finished incorporating the changes discussed at the last
meeting and published a new draft:

https://www.ietf.org/archive/id/draft-parecki-oauth-first-party-apps-00.html

Highlights include:

• Renamed "device_session" to "auth_session" (feel free to continue
bikeshedding this during the next meeting)
• Added a way for the AS to indicate that the client should bounce out to a
browser
• Described how to use DPoP in conjunction with this spec
• Added example of using a passkey to get an authorization code

Here is the full list of issues we addressed in this revision:

https://github.com/aaronpk/oauth-first-party-apps/milestone/2?closed=1

I look forward to continuing the discussion at IETF 118!

---
Aaron Parecki
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Protected Resource Metadata

[Aaron Parecki]

Hi all,

Mike and I took some time to categorize all the feedback on the Protected
Resource Metadata on the mailing list and moved them to GitHub:

https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/issues

Feel free to chime in on any of the threads there. We will be addressing
the feedback from the list and publishing a new draft before IETF 118.

---
Aaron Parecki
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List

[Aaron Parecki]

I support adoption


On Sat, Sep 30, 2023 at 5:53 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is an official call for adoption for the *JWT and CWT Status List*
> draft:
> https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/
>
> Please, reply *on the mailing list *and let us know if you are in *favor *
> or* against *adopting this draft as WG document, by *Oct 13th*.
>
> Regards,
>  Rifaat & Hannes
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7642)

[Aaron Parecki]

I disagree with this errata. The original text is correctly representing
that the "photo-sharing service" trusts the authorization server. The
suggested text is ambiguous because it does not make clear which party is
trusting which other party.

Aaron

On Sun, Sep 17, 2023 at 11:00 AM RFC Errata System <
rfc-edi...@rfc-editor.org> wrote:

> The following errata report has been submitted for RFC6749,
> "The OAuth 2.0 Authorization Framework".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7642
>
> --
> Type: Editorial
> Reported by: Wilhelm Fast 
>
> Section: 1
>
> Original Text
> -
>  Instead, she authenticates directly with a server trusted by the
> photo-sharing service (authorization server), which issues the printing
> service delegation-
> specific credentials (access token).
>
> Corrected Text
> --
> Instead, she directly authenticates with a trusted server, the
> authorization server, which issues delegation-specific credentials, known
> as access tokens, to the printing service for controlled and secure access.
>
> Notes
> -
> The sentence is confusing, and the reader might confuse the Authorization
> Server with the Resource Server.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC6749 (draft-ietf-oauth-v2-31)
> --
> Title   : The OAuth 2.0 Authorization Framework
> Publication Date: October 2012
> Author(s)   : D. Hardt, Ed.
> Category: PROPOSED STANDARD
> Source  : Web Authorization Protocol
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7631)

[Aaron Parecki]

I agree with this errata, it should have been "authorization code". This
sentence was also removed from OAuth 2.1, since the PKCE code
challenge/code verifier mechanism is a more complete protection against
authorization code substitution.

Aaron

On Tue, Sep 5, 2023 at 6:00 AM RFC Errata System 
wrote:

> The following errata report has been submitted for RFC6749,
> "The OAuth 2.0 Authorization Framework".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7631
>
> --
> Type: Editorial
> Reported by: Daiki Usami 
>
> Section: 3.2.1
>
> Original Text
> -
> This protects the client from substitution of the authentication code.
>
> Corrected Text
> --
> This protects the client from substitution of the authorization code.
>
> Notes
> -
> It will be a bit confusing to figure out if it is a MAC or an
> authorization code.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC6749 (draft-ietf-oauth-v2-31)
> --
> Title   : The OAuth 2.0 Authorization Framework
> Publication Date: October 2012
> Author(s)   : D. Hardt, Ed.
> Category: PROPOSED STANDARD
> Source  : Web Authorization Protocol
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC for Browser-based Apps

[Aaron Parecki]

> An XSS compromise would allow an attacker to call the resource server
from the browser context through the BFF, which would lead to the same
catastrophous result as doing it from another context.

There is a huge difference between being able to access resources through
the user's browser while it's online vs being able to access resources
without the browser's involvement.

Additionally, in many cases, the BFF exposes only a subset of actions of
the resource server to the client. Or put another way, sometimes access
tokens can access more resources than just the ones the BFF can access.
This obviously doesn't apply to everyone, but it's still common enough to
be significant. This is briefly mentioned in the security considerations
already:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-reducing-the-impact-of-toke

Aaron


On Mon, Aug 28, 2023 at 8:51 AM Yannick Majoros  wrote:

> An XSS compromise would allow an attacker to call the resource server from
> the browser context through the BFF, which would lead to the same
> catastrophous result as doing it from another context.
>
> Cookies are sent automatically, potentially to resources which shouldn't
> get it. Same threat level as a token that is too broadly scoped, really.
>
> You really have a point about refresh tokens here, but they are a
> separate, real issue. Refresh tokens should be avoided whenever you can do
> without. Any pattern that can keep them safe is on the same level, but
> their safety is always relative. They make any attack worse, indeed (and
> that is also true for BFFs in some scenario's). This isn't specifically
> about BFFs.
>
> Le lun. 28 août 2023 à 17:38, Aaron Parecki  a écrit :
>
>> > BFFs are not any safer, XSS or any successful malicious javascript
>> execution has the same end effect
>>
>> As described in the draft as well as in this email thread, this is
>> incorrect.
>>
>> An XSS compromise of the BFF architecture results in the attacker being
>> able to make requests to the BFF with the legitimate user's cookie, as long
>> as the user's browser is active. An XSS compromise of a SPA results in the
>> attacker being able to obtain access tokens (and possible refresh tokens),
>> which results in the attacker being able to access the resource server
>> directly, outside of the context of the user's browser, which may allow the
>> attacker to access far more data than the browser app alone, and for a
>> longer period of time.
>>
>> The difference between these threats is extremely significant.
>>
>> Aaron
>>
>> On Mon, Aug 28, 2023 at 8:14 AM Yannick Majoros 
>> wrote:
>>
>>> My last comment was rather ironic: user-facing applications are
>>> dangerous (security is hard, which I say nothing with), and that is true
>>> for any scheme.. BFFs are not any safer, XSS or any successful malicious
>>> javascript execution has the same end effect (=game over, complete
>>> compromise of authenticated calls), and there was still no
>>> factual demonstration of multiple levels of security here. See my detailed
>>> explanations.
>>>
>>> Le lun. 28 août 2023 à 11:35, Steinar Noem  a écrit :
>>>
>>>> I think this is a great discussion, and it seems to me that Yannicks
>>>> last comment is basically what Phillippe is trying to point out..
>>>> I just wanted to remind the authors about a couple of things that we
>>>> briefly discussed during OSW in London.
>>>>
>>>> Although it might not be directly relevant for this discussion I do
>>>> think that it might be a good idea that the spec mentions that:
>>>>
>>>>- The level of security you require for any client is often a
>>>>reflection of the sensitivity of the information that the API exposes. 
>>>> You
>>>>will have different requirements for confidential information than for 
>>>> open
>>>>data. An example of a similar recommendation can be found in the HTTP
>>>>Semantics specification: https://httpwg.org/specs/rfc9110.html#GET
>>>>- In my domain it is most often the owner of the API (the data
>>>>controller) who defines and approves the level of security which it 
>>>> finds
>>>>to fit their responsibilities (e.g. legal obligations) - although in 
>>>> some
>>>>cases it might be both the data provider and the data consumer. Meaning 
>>>> -
>>>>this BCP might be equally important for the API-owner as it is to the
>>>>client developer.
>>

Re: [OAUTH-WG] WGLC for Browser-based Apps

[Aaron Parecki]

oblem with a browser-only client is that the attacker
>>>>> with control over the client has the ability to run a silent Authorization
>>>>> Code flow, which provides them with an independent set of tokens*
>>>>> [...]
>>>>> *> **The security differences between a BFF and a browser-only app
>>>>> are not about token storage, but about the attacker being able to run a 
>>>>> new
>>>>> flow to obtain tokens.*
>>>>> [...]
>>>>> *> Again, the security benefits of a BFF are not about stoken storage.
>>>>> Even if you find the perfect storage solution for non-extractable tokens 
>>>>> in
>>>>> the browser, an attacker still controls the client application and can
>>>>> simply request a new set of tokens. *
>>>>>
>>>>> Truth is: no, you can't start a new authentication flow and get the
>>>>> authorization code back in the main thread. I'm talking about the
>>>>> redirection scenario, which I'm the most familiar with, but it would
>>>>> probably apply to the "message" one as well (which is new to me and seems
>>>>> to be ashtoningly legit due to vague "for example" wording in the OAuth2
>>>>> spec :-) ).
>>>>>
>>>>> The service worker, according to
>>>>> https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope/fetch_event#description
>>>>> , just intercepts the authorization code, gets a token, and never sends it
>>>>> back to the main code.
>>>>>
>>>>> But don't trust me on my words: what about demonstrating our claims
>>>>> with actual code, and as such create a shorter, simpler, but more
>>>>> constructive discussion?
>>>>>
>>>>> The demonstration in its current form would not lead to a successful
>>>>> compromise of a good implementation of access tokens handled by a service
>>>>> worker.
>>>>>
>>>>> Yannick
>>>>>
>>>>>
>>>>> Le sam. 26 août 2023 à 14:20, Philippe De Ryck <
>>>>> phili...@pragmaticwebsecurity.com> a écrit :
>>>>>
>>>>>> My responses inline.
>>>>>>
>>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> The document is about "OAuth 2.0 for Browser-Based Apps". Its
>>>>>> abstract further explains that it "details the security considerations 
>>>>>> and
>>>>>> best practices that must be taken into account when developing
>>>>>> browser-based applications that use OAuth 2.0.".
>>>>>>
>>>>>> As such, detailing security considerations is important. I share the
>>>>>> point of view that basing web applications on proven concepts is 
>>>>>> important.
>>>>>> The approaches detailed in the document have all their advantages
>>>>>> and disadvantages.
>>>>>>
>>>>>>
>>>>>> We have discussed the topic of browser-based apps in depth at the
>>>>>> OAuth Security Workshop last week. I am also working with Aaron Parecki 
>>>>>> on
>>>>>> updating the specification to more accurately reflect these advantages 
>>>>>> and
>>>>>> disadvantages. Updates will go out in the coming days/weeks, so we more
>>>>>> than welcome concrete feedback on the content there.
>>>>>>
>>>>>> There are 2 main approaches to browser-based applications security.
>>>>>> One of them is to store security credentials at the frontend. The other 
>>>>>> one
>>>>>> is to use cookies and a BFF. Though common practice, there is nothing
>>>>>> fundamentally more secure about them in a demonstrable way. Different
>>>>>> approaches, different characteristics and security assumptions. Nobody 
>>>>>> can
>>>>>> prove that either approach is better, just that there are different
>>>>>> concerns.
>>>>>>
>>>>>> Handling security in BFFs relies on cookies that cannot be read by
>>>>>> the javascript application. This mechanism provides some reliable
>>>>>> protection about the cookie itself t

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Aaron Parecki]

Hi Jaimandeep,

As with many OAuth extensions, this is not obligatory to implement unless
you need the functionality it provides. Many of the concerns you mention
are referenced in the security considerations section of the draft already,
and we would of course be happy to further expand that section as
appropriate.

As we presented during the last two IETF meetings, there are many use cases
that would benefit from this draft that currently don't have an
interoperable solution. I would suggest you review those presentation
recordings so better understand the use cases.

Aaron




On Fri, Aug 25, 2023 at 12:31 PM Jaimandeep Singh  wrote:

> I do not support the adoption because of following:
>
> 1. Increased Attack Surface and Information Disclosure: The proposed draft
> inherently expands the attack surface by allowing the retrieval of detailed
> information about the protected resources held with a particular resource
> server, as outlined in section 3.1. We are inadvertently exposing the
> resources supported by the protected resource server. The secondary URIs
> which correspond to each of the protected resources further expands the
> potential attack vectors. To illustrate, if a protected resource server
> supports resources from 1 to 10, and a client requests metadata for all
> these resources, it leads to 11 requests (1 + 10). This exposes a total
> of 11 URIs to potential attackers with information disclosure.
>
> 2. Lack of Client Verification and Potential DDoS Vulnerability: There is
> absence of client application verification before it accesses the APIs.
> This can lead to the possibility of malicious client applications
> initiating Distributed Denial of Service (DDoS) attacks.
>
> 3. Impact on Processing Time due to Multiple Resources: The need to
> wildcard match/support numerous secondary URIs based on the number of
> protected resources could lead to increased processing time.
>
> 4. Strengthening the Existing System with Adequate Error Codes: Our
> existing OAuth RFC, can handle this issue gracefully by incorporating error
> codes. This ensures that, at the very least, access tokens are verified
> before any specific information is disclosed.
>
> Thanks
> Jaimandeep Singh
>
> On Thu, Aug 24, 2023 at 12:32 AM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>> All,
>>
>> This is an official call for adoption for the *Protected Resource
>> Metadata* draft:
>> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>>
>> Please, reply on the mailing list and let us know if you are in favor of
>> adopting this draft as WG document, by *Sep 6th.*
>>
>> Regards,
>>  Rifaat & Hannes
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> Regards and Best Wishes
> Jaimandeep Singh
> LinkedIn 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Aaron Parecki]

I support adoption.

Aaron


On Wed, Aug 23, 2023 at 8:02 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is an official call for adoption for the *Protected Resource
> Metadata* draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
> Please, reply on the mailing list and let us know if you are in favor of
> adopting this draft as WG document, by *Sep 6th.*
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
---
Aaron Parecki
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC for Browser-based Apps

[Aaron Parecki]

Hi Philippe, I look forward to discussing this with you at the OAuth
Security Workshop later this month. Like I mentioned to you last year, I
want to make sure your concerns are adequately captured in the document.

The goal for this draft is not to present the one "best" architecture for
browser-based apps, since as you mentioned, there are many different ways
attacks can happen and different trade-offs with the different patterns.

As to Brock's comment, the point of this draft is to document the existing
established patterns *as well as their limitations* so that someone
implementing OAuth in browser-based apps knows the limits of the pattern
they are choosing. We are not saying that any given recommendation in this
draft has no possible attack vectors, since that's not the reality of the
world in browsers.

Aaron

On Thu, Aug 10, 2023 at 7:16 AM Brock Allen  wrote:

> I agree with Philippe here.
>
> If there are already documented attack vectors working around the
> techniques presented in this document, then I worry it will give people a
> false sense of security if they follow the guidance contained therein.
>
> -Brock
>
> On 8/10/2023 2:51:35 AM, Philippe De Ryck <
> phili...@pragmaticwebsecurity.com> wrote:
> In my opinion, *this document is not ready to be published as an RFC*.
>
> In fact, I will be at the OAuth Security Workshop in two weeks to discuss
> exactly this (See "The insecurity of OAuth 2.0 in frontends" here:
> https://oauth.secworkshop.events/osw2023/agenda-thursday). My hope is
> that my presentation can spark the necessary discussion to identify a path
> forward to make the RFC useful for practitioners building browser-based
> apps.
>
> I don't have the resources available to write a lengthy email detailing my
> objections. I just want to point out that I've raised these points on the
> mailing list in the past, and there have been a couple of threads on this
> very list suggesting how to move this document forward (e.g., identify
> concrete threat models). I've also given a talk at NDC Security earlier
> this year (https://www.youtube.com/watch?v=OpFN6gmct8c) about how the
> security mechanisms proposed in this document fall short. This video has
> been posted to this list before as well.
>
> Here are a couple of suggestions that I believe would improve this
> document:
>
> - Clearly identify the danger of malicious JS (exfiltrating existing
> tokens is only one threat, and the most trivial one at that)
> - State the baseline achievable level of security in light of existing XSS
> vulnerabilities (i.e., session riding, where the attacker controls the
> frontend)
> - Identify different desired levels of security for a client application
> (e.g., a "public recipe app" vs "eHealth"). Existing work can help, such as
> the OWASP ASVS levels (
> https://github.com/OWASP/ASVS/blob/master/4.0/en/0x03-Using-ASVS.md)
> - Define which levels of security certain mechanisms can offer (e.g., RTR
> for level 1, TMI-BFF for level 2, BFF for level 3)
> - Remove unproven and overly complicated solutions (i.e., the service
> worker approach)
>
> As stated before, I'll be at OSW in London in 2 weeks and would be happy
> to discuss this further.
>
> Kind regards
>
> Philippe
>
> —
> *Pragmatic Web Security*
> *Security for developers*
> https://pragmaticwebsecurity.com
>
> On 30 Jul 2023, at 17:46, Rifaat Shekh-Yusef 
> wrote:
>
> All,
>
> This is a *WG Last Call *for the* Browser-based Apps* draft.
> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-14.html
>
> Please, review this document and reply on the mailing list if you have any
> comments or concerns, by *August 11th*.
>
> Regards,
>  Rifaat & Hannes
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Collective name for attacks on cross-device flows: Cross-Device Consent Phishing (CDCP)

[Aaron Parecki]

I like it, it's definitely the best out of the list.

Aaron

On Thu, Jun 15, 2023 at 7:57 AM Pieter Kasselman  wrote:

> Hi folks, one of the discussion points at IETF 116 for the cross-device
> security BCP was finding a collective name for the exploits of the cross
> device flows we were seeing. We got several suggestions since then (see
> list below).
>
>
>
> We are thinking of adopting the term “Cross-Device Consent Phishing
> (CDCP)” given that it describes the scope of the attacks (cross-device),
> the purpose of the attacks (obtaining user consent), and the technique
> (phishing, and other social engineering techniques).
>
>
>
> Does this feel like a good descriptive name to adopt?
>
>
>
> The list of names that was suggested over the last few months:
>
>
>
>1. Cross-Device Consent Phishing
>2. Illicit Consent Grant Attack
>3. Attacker-in-the-Middle Attack
>4. Authorization Context Manipulation Attack
>5. Authorization Context Manipulation Exploit
>6. "Cross-Device Authorization Exploit"
>7. "Social Engineering Token Theft"
>8. "Authorization Flow Manipulation Exploit"
>9. Context Manipulation Authorization Exploit
>10. Zishing
>11. Azishing
>12. FlowJack
>13. AuthJack
>14. TokenJack
>15. Permitphishing,
>16. Authishing
>
>
>
> Cheers
>
>
>
> Pieter
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] BCP: Mix-Up Attacks, Implicit Grant Variant

[Aaron Parecki]

Hi Warren, this is described in detail in the linked paper on page 31 if
you need further clarification.

Aaron


On Wed, Jun 14, 2023 at 7:36 AM Warren Parad  wrote:

> That doesn't make sense to me.
>
> On Wed, Jun 14, 2023, 21:31 Daniel Fett  40danielfett...@dmarc.ietf.org> wrote:
>
>> Hi Alexander,
>> Am 14.06.23 um 15:19 schrieb Alexander Rademann:
>>
>> *Hello, everyone! Section 4.4.1 of the BCP
>> 
>> draft lists several variants of mix-up attacks; the description of the
>> Implicit grant variant reads as follows: "In the implicit grant, the
>> attacker receives an access token instead of the code; the rest of the
>> attack works as above." Given the attack description in that section, it is
>> not clear to me why an attacker would receive the access token and which
>> part the "rest of the attack" refers to. When the Implicit grant is used,
>> H-AS sends the access token (via redirect) to the user agent, which
>> extracts it and sends it to the client. However, the client does not send
>> the access token to A-AS, does it? (I hope that I didn’t overlook anything
>> in that section.)*
>>
>> * I also checked the referenced paper ;
>> there, the authors assume that the access token is sent to the
>> authorization server under the control of the attacker (or, using their
>> terminology, identity provider) to access some resource. [Appendix B, p.
>> 31ff] Perhaps this (or some similar) assumption should be added to the
>> description of this variant?*
>>
>> The underlying assumption is that when then user selected to use A-AS in
>> the beginning, the access token would also be used with a Resource Server
>> under the attacker's control.
>>
>> -Daniel
>>
>>
>> * I'm sorry if I missed anything or if this has already been addressed
>> before, I'm new to this mailing list and did not find anything in the
>> archives. Kind regardsAlex*
>>
>> ___
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] BCP: Mix-Up Attacks, Implicit Grant Variant

[Aaron Parecki]

I've created a pull request to update this section here:
https://github.com/oauthstuff/draft-ietf-oauth-security-topics/pull/82/files

Aaron

On Wed, Jun 14, 2023 at 6:47 AM Aaron Parecki  wrote:

> Hi Alex,
>
> I see what you mean, in Section 4.4.1 with the implicit flow, the sequence
> ends with the redirect back to the client from H-AS with the access token.
> Steps 5 and 6 don't happen with the implicit flow, so "works as above"
> isn't descriptive enough.
>
> The paper describes a slightly different way the attacker gets the access
> token, which is after the client attempts to use the access token from H-AS
> to retrieve resources from A-RS or retrieve user info from A-AS. I believe
> the description of the implicit variant in the Security BCP should be
> updated to make this more clear.
>
> Thanks!
>
> Aaron
>
>
>
> On Wed, Jun 14, 2023 at 6:23 AM Alexander Rademann <
> alexander.radem...@web.de> wrote:
>
>>
>>
>> *Hello, everyone!Section 4.4.1 of the BCP
>> <https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-23.html#section-4.4.1>
>> draft lists several variants of mix-up attacks; the description of the
>> Implicit grant variant reads as follows: "In the implicit grant, the
>> attacker receives an access token instead of the code; the rest of the
>> attack works as above."Given the attack description in that section, it is
>> not clear to me why an attacker would receive the access token and which
>> part the "rest of the attack" refers to. When the Implicit grant is used,
>> H-AS sends the access token (via redirect) to the user agent, which
>> extracts it and sends it to the client. However, the client does not send
>> the access token to A-AS, does it? (I hope that I didn’t overlook anything
>> in that section.)*
>>
>>
>>
>> *I also checked the referenced paper <https://arxiv.org/abs/1601.01229>;
>> there, the authors assume that the access token is sent to the
>> authorization server under the control of the attacker (or, using their
>> terminology, identity provider) to access some resource. [Appendix B, p.
>> 31ff] Perhaps this (or some similar) assumption should be added to the
>> description of this variant?I'm sorry if I missed anything or if this has
>> already been addressed before, I'm new to this mailing list and did not
>> find anything in the archives.Kind regardsAlex*
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] BCP: Mix-Up Attacks, Implicit Grant Variant

[Aaron Parecki]

Hi Alex,

I see what you mean, in Section 4.4.1 with the implicit flow, the sequence
ends with the redirect back to the client from H-AS with the access token.
Steps 5 and 6 don't happen with the implicit flow, so "works as above"
isn't descriptive enough.

The paper describes a slightly different way the attacker gets the access
token, which is after the client attempts to use the access token from H-AS
to retrieve resources from A-RS or retrieve user info from A-AS. I believe
the description of the implicit variant in the Security BCP should be
updated to make this more clear.

Thanks!

Aaron



On Wed, Jun 14, 2023 at 6:23 AM Alexander Rademann <
alexander.radem...@web.de> wrote:

>
>
> *Hello, everyone!Section 4.4.1 of the BCP
> 
> draft lists several variants of mix-up attacks; the description of the
> Implicit grant variant reads as follows: "In the implicit grant, the
> attacker receives an access token instead of the code; the rest of the
> attack works as above."Given the attack description in that section, it is
> not clear to me why an attacker would receive the access token and which
> part the "rest of the attack" refers to. When the Implicit grant is used,
> H-AS sends the access token (via redirect) to the user agent, which
> extracts it and sends it to the client. However, the client does not send
> the access token to A-AS, does it? (I hope that I didn’t overlook anything
> in that section.)*
>
>
>
> *I also checked the referenced paper ;
> there, the authors assume that the access token is sent to the
> authorization server under the control of the attacker (or, using their
> terminology, identity provider) to access some resource. [Appendix B, p.
> 31ff] Perhaps this (or some similar) assumption should be added to the
> description of this variant?I'm sorry if I missed anything or if this has
> already been addressed before, I'm new to this mailing list and did not
> find anything in the archives.Kind regardsAlex*
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Technical Errata Reported] RFC8693 (7511)

[Aaron Parecki]

This errata is incorrect and should be rejected. RFC7523 defines two
separate uses of JWTs, one is client authentication and the other is an
authorization grant. When using RFC7523 as client authentication, you can
use any type of authorization grant, including the token exchange grant.
See https://datatracker.ietf.org/doc/html/rfc7523#section-2.2

Aaron

On Mon, May 8, 2023 at 8:57 AM RFC Errata System 
wrote:

> The following errata report has been submitted for RFC8693,
> "OAuth 2.0 Token Exchange".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7511
>
> --
> Type: Technical
> Reported by: Jesse Estum 
>
> Section: 2.1
>
> Original Text
> -
> Client authentication to the authorization server is done using the
> normal mechanisms provided by OAuth 2.0. Section 2.3.1 of [RFC6749]
> defines password-based authentication of the client, however, client
> authentication is extensible and other mechanisms are possible. For
> example, [RFC7523] defines client authentication using bearer JSON Web
> Tokens (JWTs) [JWT]. The supported methods of client authentication and
> whether or not to allow unauthenticated or unidentified clients are
> deployment decisions that are at the discretion of the authorization
> server.
>
> Corrected Text
> --
> Client authentication to the authorization server is done using the
> normal mechanisms provided by OAuth 2.0. Section 2.3.1 of [RFC6749]
> defines password-based authentication of the client, however, client
> authentication is extensible and other mechanisms are possible. The
> supported methods of client authentication and whether or not to allow
> unauthenticated or unidentified clients are deployment decisions that
> are at the discretion of the authorization server.
>
> Notes
> -
> The specific example of authentication with RFC7523 would require
> "grant_type" value of "urn:ietf:params:oauth:grant-type:jwt-bearer",
> however this directly conflicts with RFC8693 as it requires "grant_type"
> value of "urn:ietf:params:oauth:grant-type:token-exchange".
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8693 (draft-ietf-oauth-token-exchange-19)
> --
> Title   : OAuth 2.0 Token Exchange
> Publication Date: January 2020
> Author(s)   : M. Jones, A. Nadalin, B. Campbell, Ed., J. Bradley,
> C. Mortimore
> Category: PROPOSED STANDARD
> Source  : Web Authorization Protocol
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Httpdir telechat review of draft-ietf-oauth-step-up-authn-challenge-13

[Aaron Parecki]

Hi Mark, thanks for the review.

On the terminology nits, I wanted to add some context.

"Resource server" is a term used throughout the OAuth specs, defined in
RFC6749. The term "resource" is used to distinguish the resource server
from the authorization server. It would be incredibly confusing and
ambiguous to refer to this only as the "server".

Again, the term "resource request" uses "resource" to distinguish this
request from the "authorization request" that the client makes.

The term "protected resource" is also defined in RFC 6749, which is why
it's used in this draft.

Many of the other OAuth extensions also use these terms, and usually have a
section in the introduction that mention these terms come from RFC 6749. (
https://www.rfc-editor.org/rfc/rfc9207#section-1.1
https://www.rfc-editor.org/rfc/rfc9068#section-1.2) I believe it would be a
good idea to add this paragraph to this draft as well for clarity.

On the WWW-Authenticate header, this draft is extending RFC6750's use of
the WWW-Authenticate header, not trying to extend HTTP's definition of it.
Thanks for the reference to RFC9110 though because I just checked the
in-progress OAuth 2.1 draft (which updates RFC6750) and it still references
the older RFC7235, so I will go update that to reference RFC9110 instead.

Thanks,

---
Aaron Parecki


On Tue, Apr 4, 2023 at 10:19 PM Mark Nottingham via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Mark Nottingham
> Review result: Not Ready
>
> # HTTPDIR review of drat-ietf-oauth-step-up-authn-challenge-13
>
> I am an assigned HTTP directorate reviewer for
> draft-ietf-masque-connect-ip.
> These comments were written primarily for the benefit of the ART Area
> Directors. Document editors and shepherd(s) should treat these comments
> just
> like they would treat comments from any other IETF contributors and resolve
> them along with any other Last Call comments that have been received. For
> more
> details on the HTTP Directorate, see
> https://datatracker.ietf.org/group/intdir/about/.
>
> I've entered a 'not ready' position because of the first issue below; the
> remaining are relatively easy to address.
>
> ## Comments
>
> ### Global HTTP Authentication Parameters
>
> This draft seems to modify the HTTP authentication mechanism globally,
> regardless of the scheme in use. For example:
>
> "This specification introduces a new error code value for the error
> parameter
> of [RFC6750] or authentication schemes, such as [I-D.ietf-oauth-dpop],
> which
> use the error parameter"
>
> [...]
>
> "Furthermore, this specification defines additional WWW-Authenticate
> auth-param
> values to convey the authentication requirements back to the client."
>
> [...]
>
> "A client receiving an authorization error from the resource server
> carrying
> the error code insufficient_user_authentication SHOULD parse the
> WWW-Authenticate header for acr_values and max_age and use them, if
> present, in
> constructing an authorization request"
>
> If that is the intent, you need to update RFC9110 (which is likely to be
> contentious); otherwise, you need to scope it in such a way that
> authentication
> schemes 'opt into' their use.
>
> ### Header Definition
>
> "This document also introduces acr_values and max_age parameters for the
> WWW-Authenticate response header defined by [RFC6750]"
>
> RFC6750 does not define WWW-Authenticate; RFC9110 does.
>
> ## Nits
>
> I found the terminology in this draft confused, and confusing. E.g.,
>
> * Use of the term 'resource server' throughout is very jarring -- on the
> Web,
> it's just a 'resource'. The 'server' is responsible for the resource; if
> you
> mean the server, say 'server'; if you mean the resource, say 'resource'.
> Don't
> combine them.
>
> * Likewise, 'resource request' is redundant; every request is for a
> resource.
> Just say 'request'.
>
> * Similarly, the diagram on page 4 shows a 'resource server' returning a
> 'protected resource'. Resources are never transferred over the network;
> they
> send representations in responses -- one of those terms should be used.
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Draft OAuth WG Agenda @ Yokohama

[Aaron Parecki]

- *Identity Chaining *– Rifaat/Pieter (20 min)
>>>>- *Native Apps UX* – Aaron/Pieter (20 min)
>>>>- *Authorization Server Discovery *– Aaron/Ben (20 min)
>>>>- *PoP Security Architecture *– Nat (15 min)
>>>>- *Power of Attorney (PoA) Grant Type *– Olov (15 min)
>>>>
>>>>
>>>> Please, let us know if you have any comments about the above agenda.
>>>>
>>>> Regards,
>>>>  Rifaat & Hannes
>>>>
>>>> ___
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>
> --
> Regards and Best Wishes
> Jaimandeep Singh
> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
---
Aaron Parecki
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proposed OAuth Security BCP text on the use of CORS

[Aaron Parecki]

Since that is my comment referenced in the OpenID thread, I should clarify
that my intent was to have this language in the Security BCP with the
caveat that it's only applicable if your AS intends on supporting SPAs. In
other words, we're not saying all ASs SHOULD add CORS headers, only ASs
that intend on supporting SPAs. However, even if the AS does not intend on
supporting SPAs, it still MUST NOT enable CORS at the authorization
endpoint.

I don't know the best language to put in front of Mike's suggested text to
make that clear, so suggestions are welcome.

Aaron


On Tue, Mar 7, 2023 at 11:16 PM Mike Jones  wrote:

> I propose adding the following section to the OAuth Security BCP
> specification:
>
>
>
> *Usage of CORS*
>
>
>
>   The Token Endpoint,
>
>   Authorization Server Metadata Endpoint,
>
>   jwks_uri Endpoint,
>
>   Dynamic Client Registration Endpoint,
>
>   and any other endpoints directly accessed by Clients
>
>   SHOULD support the use of
>
>   Cross-Origin Resource Sharing
> (CORS)
>
>   to enable JavaScript Clients and other browser-based Clients
> to access them.
>
>   CORS MUST NOT be used at the Authorization Endpoint
>
>   as it is redirected to by the client and not directly
> accessed.
>
>
>
>
>
> Relevant background information can be found at
> https://bitbucket.org/openid/connect/issues/980 and
> https://bitbucket.org/openid/connect/pull-requests/338/errata-specified-the-use-of-cors-at
> .
>
>
>
>-- Mike
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] redirect uri and portals

[Aaron Parecki]

There is no situation in which supporting arbitrary redirects (whether from
the OAuth redirect URI or within your own app) is a good idea.

This is known as an Open Redirector, and is the basis of many attacks on
OAuth as well as other things unrelated to OAuth. OWASP has a cheat sheet
about this as well:
https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html

There was an example published just last week of combining a wildcard
redirect_uri with another open redirector to accomplish an account
takeover. It's worth reading the writeup if you're curious about the
implications of wildcard redirects within and outside of OAuth.

https://salt.security/blog/traveling-with-oauth-account-takeover-on-booking-com

Aaron

On Mon, Mar 6, 2023 at 11:31 AM Yannick Majoros  wrote:

> Thanks for your input.
>
> All of that would be quite common indeed, but in what way is it better,
> from a security perspective, than redirect URIs with wildcards?
>
> Yannick
>
> Le lun. 6 mars 2023 à 18:28, Vittorio Bertocci  a
> écrit :
>
>> In my experience the most common solution, adopted by many SDKs, is based
>> on 2.
>> Where you redirect after you concluded the token acquisition ceremony is
>> a private consideration for your app, that shouldn’t interfere with how the
>> client is registered. Oauth offers you the chance to store and retrieve
>> state, you can use that to save the initial requested URL and redirect to
>> it after the fact. If you are concerned with injections, you can always
>> sign/encryp the state to protect it from tampering.
>> All of the above is mainstream, you can observe the traffic from popular
>> SDKs to see how that works.
>> HTH
>> V.
>>
>> On Mon, Mar 6, 2023 at 09:12 Yannick Majoros  wrote:
>>
>>> *This message originated outside your organization.*
>>>
>>> --
>>>
>>> Hello,
>>>
>>> From my understanding, OAuth 2 as well as 2.1 do not allow for wildcards
>>> in redirect_uri . Now, a common requirement for a portal or company-wide
>>> website, where multiple applications are deployed, is to be able to login
>>> and come back to the page from which the login was triggered.
>>>
>>> How can this be achieved securely with OAuth?
>>>
>>> Some options:
>>> 1) passing a parameter, say *callback_uri*, around from auth request
>>> back to redirect from auth server.
>>> 2) storing some state, e.g. in session storage, and redirect after login
>>> 3) violating the specifications and just use a redirect uri with a
>>> wildcard in the last part (some implementations, like keycloak, allow that)
>>>
>>> 1) and 2) are kind of similar IMO: the application has to validate
>>> whatever context comes and redirect to the right page, akin to deep linking
>>> But then, outside of some extra validation, I'd prefer to have a
>>> standard mechanism (less bypassing the restrictions) as redirect uri than
>>> to reinvent the wheel for each application, which is what that kind of
>>> callback url does. Also, I'm not sure why that extra validation would
>>> improve things in practice: if there is a vulnerability in the application
>>> routing code leading to some vulnerable redirect, wouldn't it just be
>>> duplicated in that validation step?
>>>
>>> So, I'm tempted to go for 3, knowing we would have those mitigations:
>>> - checking at authorization server whether the redirect is to the same
>>> uri the request originally came from
>>> - PKCE will restrict reuse of the authorization code anyway
>>>
>>> What are your thoughts on how to implement that quite common feature?
>>>
>>> Best regards,
>>> --
>>> Yannick Majoros
>>> Valuya sprl
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>
> --
> Yannick Majoros
> Valuya sprl
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] redirect uri and portals

[Aaron Parecki]

I have also seen what you describe in 2, as well as a variation of that,
which is to encode the redirect in the "state" parameter, as described
(briefly) in RFC6749 https://www.rfc-editor.org/rfc/rfc6749#section-3.1.2.2

Note that using "state" to carry this redirect should only be done with a
fixed list of destinations or by using a signed "state" value like
encapsulating it in a JWT in order to avoid creating an open redirector:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.10.1

There is even a claim described in the (expired) JWT-encoded state draft to
specify this redirect target:
https://datatracker.ietf.org/doc/html/draft-bradley-oauth-jwt-encoded-state-09#section-2


Aaron


On Mon, Mar 6, 2023 at 9:28 AM Vittorio Bertocci  wrote:

> In my experience the most common solution, adopted by many SDKs, is based
> on 2.
> Where you redirect after you concluded the token acquisition ceremony is a
> private consideration for your app, that shouldn’t interfere with how the
> client is registered. Oauth offers you the chance to store and retrieve
> state, you can use that to save the initial requested URL and redirect to
> it after the fact. If you are concerned with injections, you can always
> sign/encryp the state to protect it from tampering.
> All of the above is mainstream, you can observe the traffic from popular
> SDKs to see how that works.
> HTH
> V.
>
> On Mon, Mar 6, 2023 at 09:12 Yannick Majoros  wrote:
>
>> *This message originated outside your organization.*
>>
>> --
>>
>> Hello,
>>
>> From my understanding, OAuth 2 as well as 2.1 do not allow for wildcards
>> in redirect_uri . Now, a common requirement for a portal or company-wide
>> website, where multiple applications are deployed, is to be able to login
>> and come back to the page from which the login was triggered.
>>
>> How can this be achieved securely with OAuth?
>>
>> Some options:
>> 1) passing a parameter, say *callback_uri*, around from auth request
>> back to redirect from auth server.
>> 2) storing some state, e.g. in session storage, and redirect after login
>> 3) violating the specifications and just use a redirect uri with a
>> wildcard in the last part (some implementations, like keycloak, allow that)
>>
>> 1) and 2) are kind of similar IMO: the application has to validate
>> whatever context comes and redirect to the right page, akin to deep linking
>> But then, outside of some extra validation, I'd prefer to have a standard
>> mechanism (less bypassing the restrictions) as redirect uri than to
>> reinvent the wheel for each application, which is what that kind of
>> callback url does. Also, I'm not sure why that extra validation would
>> improve things in practice: if there is a vulnerability in the application
>> routing code leading to some vulnerable redirect, wouldn't it just be
>> duplicated in that validation step?
>>
>> So, I'm tempted to go for 3, knowing we would have those mitigations:
>> - checking at authorization server whether the redirect is to the same
>> uri the request originally came from
>> - PKCE will restrict reuse of the authorization code anyway
>>
>> What are your thoughts on how to implement that quite common feature?
>>
>> Best regards,
>> --
>> Yannick Majoros
>> Valuya sprl
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Unified Singular Protocol Flow for OAuth (USPFO) Ecosystem

[Aaron Parecki]

Hi Jorge and Jaimandeep,

I wanted to clarify something about my blog post that was referenced.

The proposal that I brought up at the OAuth Security Workshop was to be
able to leverage the specific APIs provided by Apple and Google known as
"App Integrity" as this type of assertion. This is fundamentally different
than simply shipping a secret or certificate in the app, since these APIs
use OS-level primitives to create a signature which also include signing by
keys from Apple and Google. While even they admit it's not a perfect
solution, it's a much stronger signal that an app is legitimate than any
other form of client authentication the app developer could ship on their
own. You could think of Apple and Google's servers as this "Remote
Assertion Server", but it's not really something that the developer
interacts with themselves, since it's all done through OS-level APIs.

Here is the link to the slides I presented at the OAuth Security Workshop
talking about this problem:

https://speakerdeck.com/aaronpk/app-integrity-attestations-for-oauth-oauth-security-workshop-2022?slide=25

You can more or less think of the App Integrity APIs as a "magical
solution" for this, since it's nearly impossible for an attacker to
compromise. On Apple, this generates a key that lives in the secure
enclave, so can't be extracted. Again, it's not perfect, both Apple and
Google have carve-outs in their docs that say this, but it is far better
than anything the developer can do themselves.

---
Aaron Parecki


On Mon, Feb 27, 2023 at 2:29 AM Oliva Fernandez, Jorge
 wrote:

> Hi Jaimandeep,
>
>
>
> Just about the last point:
>
>
>
> "Remote assertion server" is not a new concept and is already widely used
> to prevent client impersonation in mobile apps. You may like to refer to
> Aaron's blog in this regard here
> <https://developer.okta.com/blog/2022/06/01/oauth-public-client-identity#:~:text=What%20is%20OAuth%20client%20impersonation,not%20granted%20to%20other%20clients.>.
> Our paper proposes entrusting the responsibility of verifying the client's
> integrity to a third-party endpoint in which the developer holds a stake.
> Such an endpoint is better positioned to conduct an integrity check and
> prevent client impersonation than relying solely on basic authentication,
> which is prone to leakages of client_secret.
>
>
>
> I have read Aaron's blog and could not locate any references to a "Remote
> Assertion Server" I am well acquainted with the issue of using "secrets" in
> public clients, this issue has been present since the inception of OAuth
> 2.0, and many individuals misunderstand that mobile applications or
> single-page web applications (SPA) are public clients, attempting to
> utilize them as confidential clients by employing `client_secret` (or any
> other authentication method such as `private_key_jwt`) has led to a
> significant problem of client impersonation since a browser or mobile
> application cannot securely store a "secret." In the event that a hacker
> obtains this secret, they can impersonate the OAuth client by using it.
>
> Aaron proposes a solution for this problem, as described in
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps,
> called BFF (Backend for Frontend), BFF is a proxy solution, where the
> public client (SPA or mobile application) never obtains the credentials to
> communicate with the authentication server (i.e., it never receives the
> client_secret), all the communications with the authentication server is
> perform by the BFF server, this is how the used client in OAuth can remain
> confidential since the BFF is a server that can store secrets securely.
>
> Of course, there is still the issue of "How we implement a trust
> connection between the browser/app and the BFF?" however, in this case, one
> can use something as simple as a cookie to maintain a session, if an
> attacker were to steal the cookie, they could impersonate the customer's
> session and make requests to the resource servers using the BFF as a proxy,
> but they would never obtain access to the `client_secret`, this is why this
> solution addresses the client impersonation attack.
>
> However, this is not the same scenario as for the "Remote Assertion
> Server."aAs far as I understand, this server communicates directly with the
> browser/mobile app and returns an assertion that serves as the credentials
> to communicate with the authentication server, therefore, if a hacker steal
> this assertion or is able to communicate with the assertion server by
> impersonating the client, then a client impersonation attack could occur.
> While using an assertion is better than using a client_secret, since the
> assertion will expire, if 

Re: [OAUTH-WG] Proposal for new OAuth authorization grant

[Aaron Parecki]

Here's a version of this that my colleague wrote up in August for this
grant, we're definitely interested in exploring this further. It is also
missing the nonce/server challenge part, but it's a start.

https://github.com/jaredhanson/id-oauth-fido2/blob/main/draft.txt

Aaron


On Fri, Dec 23, 2022 at 1:37 PM David Chadwick <
d.w.chadw...@verifiablecredentials.info> wrote:

> Yes, I already proposed this to the OpenID4VCs working group. You can see
> my proposal here
>
>
> https://bitbucket.org/openid/connect/issues/1542/support-for-fido-authentication
>
> This proposes two new authorization grant types of "FIDO Registration" and
> "FIDO Authentication".
>
> Kind regards
>
> David
> On 23/12/2022 00:40, Malla Simhachalam wrote:
>
> Hello All,
>
>  Hope you are all doing great. We have been thinking of creating a
> proposal for a new OAuth2 authorization grant based on the FIDO
> credentials, please let us know your thoughts so that we can put together a
> draft proposal.
>
> /**
>
> Abstract: FIDO Profile for OAuth2.0 Authorization Grants
>
> Fast Identity Online (FIDO) and WebAuthn are open standards that define
> strong cryptographic credentials that are alternatives to passwords for
> accessing websites and apps with secure and faster login experiences for
> users. FIDO and WebAuthn protocols have been developed through FIDO
> Alliance and W3C standard bodies. The OAuth 2.0 Authorization Framework [
> RFC6749 ] provides a method for
> making authenticated HTTP requests to a resource using an access token.
> Access tokens are issued to third-party clients by an authorization server
> (AS) with the (sometimes implicit) approval of the resource owner.  In
> OAuth, an authorization grant is an abstract term used to describe
> intermediate credentials that represent the resource owner authorization.
> An authorization grant is used by the client to obtain an access token.
> Several authorization grant types are defined to support a wide range of
> client types and user experiences.  OAuth also allows for the definition of
> new extension grant types to support additional clients or to provide a
> bridge between OAuth and other trust frameworks.
>
> This proposal defines a new authorization grant and how FIDO credentials
> can be used to obtain an access token. FIDO credentials are resource owners
> credentials directly as an authorization grant to obtain an access token.
> The credentials should only be used when there is a high degree of trust
> between the resource owner and the client. Even though this grant type
> requires direct client access to the resource owner credentials, the
> resource owner credentials are used for a single request and are exchanged
> for an access token.
>
>
> Token endpoint sample:
>
> POST v1/oauth2/token HTTP/1.1
>
> Host: authz.example.net
>
> Content-Type: application/x-www-form-urlencoded
>
> grant_type=urn:ietf:params:oauth:grant-type:webauthn-assertion
>
>  _assertion=
>
> :
>
> HTTP/1.1 200 OK
>
> Content-Type:application/json
>
> {
>
> “access_token”  : “A23.xjHEJEH830JLD”,
>
> “expires_in” : 900
>
> }
> ***/
>
> Thanks,
> Malla
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Protected Resource Metadata

[Aaron Parecki]

There is significant overlap between this draft and the concepts brought to
the OAuth WG at the last IETF meeting by Ben Schwartz, which he also
presented to the HTTPAPI WG. After that meeting, I volunteered to work with
Ben on adapting his concepts to a model that would fit better within the
OAuth framework. I published an early draft, which I am planning on
presenting at the next IETF meeting.
https://datatracker.ietf.org/doc/draft-parecki-oauth-authorization-server-discovery/

During the HTTPAPI and OAuth sessions at IETF 115, there were many concerns
expressed by various people in the groups about establishing and enabling
this kind of relationship, which would also apply to this Resource Metadata
draft. I believe there should be further discussions about the concepts
described here as well as how best to enable other working groups to take
advantage of this kind of relationship between an RS and AS before adopting
this particular draft.

Aaron



On Sat, Jan 28, 2023 at 5:21 PM David Waite  wrote:

> I support adoption by the working group.
>
> -DW
>
> On Jan 24, 2023, at 2:38 AM, Giuseppe De Marco 
> wrote:
>
> Hello everybody,
>
> I would like to bring to your attention this expired draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
> I propose the take up this individual draft for its adoption as an
> official internet draft.
> The reason I ask this is that there are implementations of this draft born
> with the need to have metadata for entities of type RS.
>
> The implementation of which I am aware concerns the Italian "Attribute
> Authorities" [0]. OpenID Federation draft also defines the metadata of the
> oauth_resource type [1], taking up the elements defined in the draft in
> question. Recently, an interesting reflection seems to have arisen also in
> OpenID4VCI/OpenID4VP [2].
>
> Thank you for your attention, I hope to read your valuable feedback soon,
> best
>
> [0] https://italia.github.io/spid-cie-oidc-docs/en/metadata_aa.html
> [1]
> https://openid.net/specs/openid-connect-federation-1_0.html#section-4.7
> [2]
> https://bitbucket.org/openid/connect/issues/1781/do-new-entity-types-required-for-oid4vp
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] DPoP examples missing client_id

[Aaron Parecki]

In section 5, the example access token requests are missing either the
client_id parameter in the POST body or the client authentication in the
HTTP header.

https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-11.html#section-5

Given that DPoP is primarily targeted at public clients, I would recommend
adding the client_id parameter to the POST body in the example. This goes
for both the authorization_code grant as well as the refresh_token grant.

I believe this is a purely editorial change since DPoP doesn't change any
requirements about client authentication or the client_id parameter.

---
Aaron Parecki
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth2 Client Discovery

[Aaron Parecki]

While we're talking about prior art, I should also mention that the
IndieAuth extension of OAuth 2 has been using URLs as client IDs since
about 2012. (Disclosure: I am the editor of the spec)

Since 2012, the spec has matured and was published as a W3C Note in 2018
while the W3C Social Web Working Group was active. (
https://www.w3.org/TR/indieauth/) Currently, the spec is maintained in the
IndieWeb community, the latest update was in February 2022:
https://indieauth.spec.indieweb.org/20220212/

Because the premise of this scenario is that the user may have no prior
relationship with an application they are authorizing via an OAuth flow,
and the applications have no prior relationship with the authorization
server, naturally we want to provide as much context to the user about the
application as possible. If there is no prior relationship between either
the user and client or the client and authorization server, it's an
inherently risky situation. Should the user believe any self-asserted
information by the client? Probably not. In fact, the only information that
the user can truly "verify" is the redirect URL. Any information (name,
logo, etc) provided by the client at its client_id URL (regardless of
whether that is a .well_known URL or the client_id URL itself as JSON or
HTML) ultimately can't be trusted. If the redirect_uri shares the same
hostname of the client_id then that's a good sign that nothing phishy is
happening.

For this reason, the IndieAuth spec has put far less emphasis on client
metadata discovery vs making the rest of the OAuth flow work by having the
client_id be a URL. There is a method of client metadata discovery defined,
but it's always secondary to making sure the user can see the redirect URL
(or the client identifier if it has the same hostname as the redirect URL),
since ultimately that is where the authorization code will be sent.

This is why using a client_id that contains human-readable information is
so critical to the security of the flow. When the client_id is something
that the user can click on and visit, they can then see more information
about which application they are granting access to. It's very common that
applications in this space will have a web page about them, at the very
least a landing page with links out to app stores, so it's not a huge
stretch of the imagination.

It's worth thinking about these types of privacy and security
considerations of any form of this type of unregistered OAuth client.

Aaron Parecki





On Tue, Dec 13, 2022 at 9:30 AM Dmitry Telegin  wrote:

> Hello Tobias, thanks for the draft! In regards to prior art, I'd like to
> mention Solid Project and their OIDC flavor, Solid-OIDC:
> https://solid.github.io/solid-oidc/#clientids-document
>
> They're using a similar approach (and have been for years), though with
> some differences:
> - client_id points to a URL that must resolve to the client metadata
> document directly (no .well-known/* used);
> - the document's format is JSON-LD, a superset of JSON.
>
> In order to maintain compatibility with Solid and similar existing
> technologies, would it make sense to mention that:
> - while retrieving client metadata, AS should recognize not only
> application/json, but application/ld+json (or maybe even
> application/*+json, as per
> https://datatracker.ietf.org/doc/html/rfc6839#section-3-1)?
> - any unknown fields (like JSON-LD "@context") must be ignored?
>
> On an unrelated note, it would be nice to cover the issue of caching the
> client metadata on the AS side. Obviously, we wouldn't want to re-request
> the metadata upon every request to the authorization endpoint. Would RFC
> 9111 suffice here? If so, which subset should be guaranteed to be supported
> by the AS?
>
> Thanks,
> Dmitry
>
> On Wed, Nov 9, 2022 at 8:36 PM Tobias Looker  40mattr.glo...@dmarc.ietf.org> wrote:
>
>> Hi Ben,
>>
>> See below for some thoughts.
>>
>> > I'm having trouble understanding the precise URL structures that are
>> used here.  Can client_uri include a nontrivial path?  Why is it necessary
>> to repeat client_uri in the response JSON?
>>
>> The intent here is to follow how "OAuth 2.0 authorization metadata" works
>> (RFC 8414) which requires the client resolving the authorization server
>> metadata to check that the issuer in the resolved document matches the
>> issuer URL they started the resolution with, see below for the relevant
>> extract from RFC 8414.
>>
>> "
>>
>> The "issuer" value returned MUST be identical to the authorization
>>server's issuer identifier value into which the well-known URI string
>>was inserted to create the URL used to retrieve the metadata.  If
>>these values are not identical, the data contained in th

Re: [OAUTH-WG] OAuth for Browser-Based Apps Draft 12

[Aaron Parecki]

Thank you, you're absolutely correct. I've updated a few uses of that to
something hopefully more accurate. There are a few more uses of "DOM" still
and I would love someone who has more experience with browsers than me to
review those for accuracy as well! Thanks!

Latest editor's draft:

https://drafts.oauth.net/oauth-browser-based-apps/draft-ietf-oauth-browser-based-apps.html

Aaron

On Wed, Dec 7, 2022 at 12:52 AM Thomas Broyer  wrote:

>
>
> On Wed, Dec 7, 2022 at 1:07 AM Aaron Parecki  40parecki@dmarc.ietf.org> wrote:
>
>> Hi all,
>>
>> I just published a revised version of OAuth for Browser-Based Apps based
>> on the feedback and discussion at IETF 115 London!
>>
>>
>> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-12.html
>>
>> The primary changes are:
>>
>> * Rephrased the architecture patterns to focus on token acquisition
>>
>
> Terminology-wise, the phrasing "code executed in the DOM" is not correct:
> the DOM is an API for manipulating the document. This should rather be
> "code executed in a browsing context" or possibly "code executed in a
> document context" (or just "in a document"?), as opposed to a "worker
> context" or service worker.
>
> Anyway, thanks for that work. I'm only using the drafts as reference in
> architecture discussions and am looking forward to this turning into an RFC.
> --
> Thomas Broyer
> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth for Browser-Based Apps Draft 12

[Aaron Parecki]

Hi all,

I just published a revised version of OAuth for Browser-Based Apps based on
the feedback and discussion at IETF 115 London!

https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-12.html

The primary changes are:

* Rephrased the architecture patterns to focus on token acquisition
* Added a new section about the various options available for storing tokens
* Added a section on sender-constrained tokens and a reference to DPoP
* Added a section discussing why not to use the Cookie API to store tokens

At this point there are no open issues on GitHub, and I have nothing else I
am planning on adding to the document. Please review if you are interested
and let me know if you have any further suggestions!

Aaron Parecki
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption: Cross-Device Flows

[Aaron Parecki]

I support adoption of this document.

Aaron

On Wed, Nov 16, 2022 at 7:52 AM Mike Jones  wrote:

> I support adoption of the cross-device flows document.
>
>
>
>-- Mike
>
>
>
> *From:* OAuth  *On Behalf Of * Joseph Heenan
> *Sent:* Wednesday, November 16, 2022 4:34 AM
> *To:* oauth 
> *Subject:* Re: [OAUTH-WG] Call for adoption: Cross-Device Flows
>
>
>
> Hi all
>
>
>
> I support adoption of this document.
>
>
>
> Thanks
>
>
>
> Joseph
>
>
>
>
>
> On 15 Nov 2022, at 14:43, Rifaat Shekh-Yusef 
> wrote:
>
>
>
> All,
>
>
>
> During the IETF meeting last week, there was a strong support for
> the adoption of the following document as a WG document:
>
> https://datatracker.ietf.org/doc/draft-kasselman-cross-device-security/
>
>
>
> This is to start a call for adoption for this document.
>
> Please, provide your feedback on the mailing list on whether you support
> the adoption of this document as a WG or not, by *Nov 29th*.
>
>
>
> Regards,
>
>  Rifaat & Hannes
>
>
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] RAR WGLC feedback

[Aaron Parecki]

In reviewing RAR, I noticed a couple things. I've submitted the editorial
suggestions below as a PR.

* Changed "the requested scope, i.e., the permission, of an access token"
to "the requested scope, i.e., the limited capability, of an access token".
Scope isn't defined as "permission" in OAuth 2.0. Permissions are often
handled by internal mechanisms other than scopes, and scopes are more about
limiting the capability of an access token.
* Clarified the description of Token Introspection
* "the user consent" -> "the user consent prompt"
* "attacker vector" -> "attack vector"

https://github.com/oauthstuff/draft-oauth-rar/pull/90

I have some other notes as well, which I didn't have a quick fix for to
suggest in the PR.

https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html#section-9.1

Would it be more appropriate to reference the JWT Access Token spec
(RFC9068) rather than just the JWT spec (RFC7519) now that it's an RFC?

https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html#section-9.2

Section 9.2 about the token introspection response is missing normative
language about whether and what specifically is recommended. The section
9.1 above does have "RECOMMENDED" for the authorization_details parameter.
I think this should match, but I'm not clear on exactly where this should
go. Perhaps this also suggests that "The authorization_details member
contains..." is ambiguous as to whether this is normative or just a
suggestion, and should be fixed as well.

https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html#section-10

Again, "The AS publishes" and "Clients announce" are missing a keyword
"MUST/SHOULD/MAY", so it's not clear whether these are required.

https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html#section-11.3

"the JSON schema id" should this be "the JSON Schema ID" or "the JSON
Schema `id`"?

https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html#section-13

Is this a "MUST" or a "must"?

"to learn the user data" - this sounds awkward, should it be "the user's
data"? Not sure if there is a better suggestion.

---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-11.txt

[Aaron Parecki]

Hello all,

With the help of a few kind folks, we've made some updates to this draft as
discussed during the last IETF meeting in Philadelphia.

You can find the current version, draft 11, here:
https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-11.html

The major changes in this version are adding two new architecture patterns,
the "Token Mediating Backend" pattern based on the TMI-BFF draft, and the
"Service Worker" pattern of using a Service Worker as the OAuth client.
I've also done a fair amount of rearranging of various parts of the
document to hopefully make more sense.

Obviously there is no clear winner in terms of which architecture pattern
is best, so instead of trying to make a blanket recommendation, the goal of
this draft is to document the pros and cons of each. If you have any input
into either benefits or drawbacks that aren't mentioned yet in any of the
patterns discussed, please feel free to chime in so we can add them to the
document! You're welcome to either reply on the list, open an issue on the
linked GitHub repository, or contact me directly. Keep in mind that only
comments on the mailing list are part of the official record.

Thanks,

Aaron Parecki


On Tue, Sep 13, 2022 at 10:42 AM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
> Title   : OAuth 2.0 for Browser-Based Apps
> Authors : Aaron Parecki
>   David Waite
>   Filename: draft-ietf-oauth-browser-based-apps-11.txt
>   Pages   : 29
>   Date: 2022-09-13
>
> Abstract:
>This specification details the security considerations and best
>practices that must be taken into account when developing browser-
>based applications that use OAuth 2.0.
>
> Discussion Venues
>
>This note is to be removed before publishing as an RFC.
>
>Discussion of this document takes place on the Web Authorization
>Protocol Working Group mailing list (oauth@ietf.org), which is
>archived at https://mailarchive.ietf.org/arch/browse/oauth/.
>
>Source for this draft and an issue tracker can be found at
>https://github.com/oauth-wg/oauth-browser-based-apps.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-11.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-browser-based-apps-11
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Certificate-bound refresh tokens and certificate expiration handling in case of the confidential clients

[Aaron Parecki]

t;> thumbprints to bind not only access tokens but also refresh tokens to
>>>> client
>>>> certificates. This happens for both public and confidential clients. As
>>>> a
>>>> result, when the certificate is replaced (e.g., it is about to expire
>>>> soon),
>>>> both access and refresh tokens are drawn unusable.
>>>>
>>>> While RFC 8705 indeed requires binding refresh token to the certificate
>>>> in
>>>> case of the public clients in Section 4 and Section 7.1, the wording is
>>>> not
>>>> that explicit for the confidential clients. More specifically, Section
>>>> 7.1
>>>> of the RFC 8705 is worded in a way which does not explicitly deny
>>>> keeping
>>>> refresh tokens alive after certificate change: it talks about binding to
>>>> client ID, thus binding "indirectly" to the certificate. Also, Section
>>>> 6.3
>>>> requires access tokens to be invalidated after certificate change and
>>>> mentions refresh tokens as typical tools for renewing them.
>>>>
>>>> >From the practical perspective, if the confidential client got a
>>>> refresh
>>>> token for the offline access and sufficient time (e.g., for a month),
>>>> this
>>>> would be quite impractical and not very user-friendly to ask a lot of
>>>> users
>>>> to give consents again when the confidential client wants to upgrade its
>>>> certificate. But seems like software vendors did not interpret the RFC
>>>> that
>>>> way.
>>>>
>>>> So, the questions:
>>>> 1) Is my assumption correct and it will not be a violation of the RFC if
>>>> refresh tokens issued to the confidential clients survive certificate
>>>> change
>>>> (e.g., by binding them to Client ID, not the certificate thumbprint)?
>>>> 2) If the answer on the 1st question is “yes”, would it be better to
>>>> provide
>>>> more clarification in the section 7.1 to avoid misinterpretations in the
>>>> future?
>>>>
>>>> Best Regards,
>>>> Mikheil Kapanadze
>>>>
>>>>
>>>>
>>>> ___
>>>> OAuth mailing list
>>>> mailto:OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>> privileged material for the sole use of the intended recipient(s). Any
>>>> review, use, distribution or disclosure by others is strictly prohibited.
>>>> If you have received this communication in error, please notify the sender
>>>> immediately by e-mail and delete the message and any file attachments from
>>>> your computer. Thank you.
>>>>
>>>> ___
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> --
>>> Regards and Best Wishes
>>> Jaimandeep Singh
>>> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
>>>
>>> ___
>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>>
>>> --
>>> Karsten Meyer zu Selhausen
>>> Senior IT Security Consultant
>>> Phone:  +49 (0)234 / 54456499
>>> Web:https://hackmanit.de | IT Security Consulting, Penetration 
>>> Testing, Security Training
>>>
>>> Is your OAuth or OpenID Connect application vulnerable to mix-up attacks? 
>>> Find out more on our 
>>> blog:https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks
>>>
>>> Hackmanit GmbHUniversitätsstraße 60 
>>> <https://www.google.com/maps/search/Universit%C3%A4tsstra%C3%9Fe+60?entry=gmail=g>
>>>  (Exzenterhaus)
>>> 44789 Bochum
>>>
>>> Registergericht: Amtsgericht Bochum, HRB 14896
>>> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. 
>>> Christian Mainka, Prof. Dr. Marcus Niemietz
>>>
>>>
>>
>> --
>> Regards and Best Wishes
>> Jaimandeep Singh
>> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>
> --
> Regards and Best Wishes
> Jaimandeep Singh
> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
>
-- 
---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Aaron Parecki]

David,

Creating "A conventional JWT with a subset of claims" is exactly the thing
this draft sets out to prevent needing to do. The problem with that
approach is the AS would have to create a new JWT with only the claims
needed for the particular presentation, so the AS would need to be both
accessible (online) by the client as well as aware of the request. These
are both properties avoided by the SD-JWT draft, perhaps these can be
clarified in the introduction.

Aaron Parecki




On Mon, Aug 1, 2022 at 9:22 AM David Chadwick <
d.w.chadw...@verifiablecredentials.info> wrote:

> thanks Guiseppe. Glad to hear that blinding claim names is now on the
> cards.
>
> This does not answer the question about why conventional JWTs with a
> subset of the claims cannot also be used
>
> Kind regards
>
> David
> On 01/08/2022 17:04, Giuseppe De Marco wrote:
>
> Hi David,
>
> This issue was already raised.
> Below the proposal for both draft and python code
>
> https://github.com/oauthstuff/draft-selective-disclosure-jwt/pull/124
>
> Regarding the privacy I'd like to have a combined presentation format that
> makes the PID/QEAA (VC) untraceable (jwe, with variable iat claim value).
> You find some open issues for joining in the discussion
>
> Best
>
> Il lun 1 ago 2022, 14:50 David Chadwick <
> d.w.chadw...@verifiablecredentials.info> ha scritto:
>
>> I would like to add a few further points.
>>
>> The age-over property is more complex than your example, because a
>> driving license only contains the date of birth. The issuing authority
>> decides which age-over properties to statically provide in the mDL and the
>> ISO standard provides an algorithm of how the wallet should respond if the
>> age-over being requested is not present in the mDL. So different mDLs may
>> contain different age-over properties and respond differently to requests
>> for age-over from two people of the same age.
>>
>> The ISO mDL selective disclosure is more privacy protecting than the
>> proposed SD-JWT because it also blinds the property names as well as the
>> values.
>>
>> The examples below do not say why the use cases cannot work if the wallet
>> has a set of conventional JWTs containing different commonly requested
>> subsets of claims, such as age or address or classes of vehicle one can
>> drive.
>>
>> Kind regards
>>
>> David
>> On 01/08/2022 13:24, Warren Parad wrote:
>>
>> This is done because network availability and privacy concerns may
>>> separate the act of acquiring the SD-JWT of a license from the issuing
>>> authority, and presenting it (such as days later during a traffic stop on a
>>> mountain road).
>>
>>
>> I think we keep pointing to "offline drivers license" as the only reason
>> we have this draft. But we still haven't made clear why the "offline
>> drivers license" actually needs this. I spent some real time thinking about
>> and came up with two hypotheticals that helped me.
>>
>> *Hypothetical 1:*
>> You are on a mountain road and a police officer pulls you over, it's late
>> at night, you have no internet, and your driver license is 100% digital.
>>
>> The officer wants to know if you live in the area, or if you are from out
>> of state. You don't want to tell the police officer your name, you click
>> some magic buttons on your device, and a QR code pops up. This QR code
>> contains only:
>>
>>- "id_token" with salted fields
>>- selective disclosure for: *address city + state*
>>
>>
>> The police officer's magic new special SD-JWT device tells them you have
>> a valid driver's license and that you live in the area. The officer is
>> either:
>>
>>- Okay with that
>>- Asks for further disclosure, which you can agree to or risk being
>>arrested and brought in for questioning.
>>
>>
>> *Hypothetical 2:*
>> You live in the US and going out to a bar. Bars in the US are infamous
>> for carding people. You want to tell them that you are over 21, but don't
>> want to tell them anything else. So you take out your digital wallet and
>> show them a QR code that only contains:
>>
>>- "id_token" with salted fields
>>- selective disclosure for: *over 21*
>>
>> The bouncer uses their magic new SD-JWT device to verify that
>> information, and can either say:
>>
>>- That's sufficient, come on in
>>- I don't believe that is yours, I need to see your picture
>>(including details), your name as well as 

Re: [OAUTH-WG] How can we define a parameter to be both OPTIONAL and REQUIRED at the same time

[Aaron Parecki]

The discussion yesterday was about the redirect_uri parameter at the token
endpoint, not at the authorization endpoint.

The redirect_uri parameter at the authorization endpoint is currently:

* optional if the client has only one redirect URI registered
* required if the client has multiple redirect URIs registered

The redirect_uri parameter at the token endpoint is currently:

* required if the authorization request included the redirect_uri
parameter, and optional otherwise

The discussion yesterday led to the conclusion that making any changes to
the parameter at the token endpoint in either direction (either always
required or omitting it entirely) would lead to worse interoperability.

Aaron



On Wed, Jul 27, 2022 at 9:38 AM Warren Parad  wrote:

> Can you explain why you think:
>>
>> But definitely cannot be both (as in the present definition).
>
>
> From a theoretical perspective, of course it can be. But perhaps there is
> a concrete reason you think otherwise, I think it would be prudent to share
> that context explicitly with an explanation here. That way we aren't
> opening old conversations in the middle of the meeting, and also it lets us
> be prepared to understand the perspective without having to dive in on the
> spot.
>
> On Wed, Jul 27, 2022 at 2:42 PM Jaimandeep Singh  40nfsu.ac...@dmarc.ietf.org> wrote:
>
>> Dear Aaron,
>>
>> 1. Yesterday you brought up an important issue of choosing "redirect_uri"
>> to be REQUIRED vs OPTIONAL parameter at the authorization code endpoint.
>> The esteemed members had their considered opinion that the definition
>> should remain as it is.
>>
>> 2. However, I am of the opinion that an important parameter like
>> "redirect_uri" needs to be more clearly defined. It can either be OPTIONAL
>> or REQUIRED, but definitely cannot be both (as in the present
>> definition). Maybe Aaron can bring up the topic again for discussion in the
>> side meeting for further deliberations.
>>
>> Regards
>> Jaimandeep Singh
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-1-06.txt

[Aaron Parecki]

I, too, would like to apologize for submitting this right before the
meeting tomorrow! The good news is that none of the changes should be
surprising, as this version incorporates all the feedback from the previous
meeting in Vienna. There are only 15 minutes on the agenda tomorrow to
cover this and my other draft, so it will mostly be a status update anyway.
I'm looking forward to diving deeper into some new topics during the side
meetings this week!

Aaron


On Sun, Jul 24, 2022 at 6:42 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
> Title   : The OAuth 2.1 Authorization Framework
> Authors : Dick Hardt
>           Aaron Parecki
>   Torsten Lodderstedt
>   Filename: draft-ietf-oauth-v2-1-06.txt
>   Pages   : 84
>   Date: 2022-07-24
>
> Abstract:
>The OAuth 2.1 authorization framework enables a third-party
>application to obtain limited access to a protected resource, either
>on behalf of a resource owner by orchestrating an approval
>interaction between the resource owner and an authorization service,
>or by allowing the third-party application to obtain access on its
>own behalf.  This specification replaces and obsoletes the OAuth 2.0
>Authorization Framework described in RFC 6749.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-06.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-1-06
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] questions around OAuth 2.0 for Browser-Based Apps

[Aaron Parecki]

I will follow up with you off-list to chat further, thanks!

Aaron

On Thu, Jun 16, 2022 at 5:50 AM Yannick Majoros  wrote:

> Hello Aaron,
>
> I'd be happy to contribute. What would be an appropriate time to talk
> about this?
>
> Thanks
>
> Le jeu. 16 juin 2022 à 04:56, Aaron Parecki  a écrit :
>
>> These are exactly the kinds of things I would expect to see in the
>> Browser-based app BCP. There isn't one best way to do things, but it's
>> worth pointing out the options and the tradeoffs of each. Some people may
>> not share the same concerns as others, but it's useful to point out the
>> different options and the tradeoffs. If you're willing to contribute to the
>> doc, I'd be happy to set up some time to talk offline about how to make
>> that happen.
>>
>> Aaron
>>
>>
>> On Wed, Jun 15, 2022 at 4:08 AM Yannick Majoros 
>> wrote:
>>
>>> Hello,
>>>
>>> >>Best practices according to whom?
>>>
>>> >This list, and documents such as:
>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics
>>>
>>> According to the explanation about rfc-6749 / oauth 2.1 and the PKCE
>>> example, it seems that document would indeed be the right place to document
>>> security issues and their workarounds.
>>>
>>> But I don't see any justification for section 6 in that document (which
>>> is also a draft BTW). That document seems to not say much about token
>>> storage, unless I'm mistaken.
>>>
>>> I am aware of discussions about potential issues about in-browser token
>>> storage and the risks they involve, mostly in case of successful XSS. As
>>> you all know, the point is also quite controversial, as there are also
>>> voices arguing that this isn't the main attention point: in case of XSS,
>>> the user is actually impersonated anyway and actually getting hold of the
>>> token is a moot point, as accessing all protected resources is then
>>> trivial, the client having all necessary technical means for that.
>>>
>>> If protecting tokens from the client (typically, javascript frontend)
>>> after successful XSS is still a point, which it seems to be for some people
>>> according to various widespread resources (though not universally so),
>>> there are options for that which are at least as secure as a stateful BFF.
>>>
>>> For example, a service worker can effectively isolate tokens and call a
>>> resource server in a safe way, with the frontend having no token access at
>>> all:
>>> [image: image.png]
>>>
>>> OTOH, a commonly (though not consensual) recommended solution is a
>>> stateful BFF. Popular common sense is that it's safe to leakage because of
>>> HTTPOnly cookies, but that's actually not the case. Here is an example of
>>> exploit, once XSS has happened (which is the actual problem, not
>>> javascript-accessible token storage):
>>> [image: image.png]
>>> This attack isn't even specific to HTTPOnly cookies: it can be made to
>>> target any form of secret (tokens or cookies) in an *authorization code*
>>> flow. But this illustrates that cookies aren't inherently safer than, say,
>>> a *service worker*.
>>>
>>> For these reasons, I suggest:
>>> - documenting that kind of security issues in the *OAuth 2.0 Security
>>> Best Current Practice* document
>>> - recommend more alternatives (e.g. service/web workers, among others),
>>> or instead even focusing attention on XSS
>>> - rewriting section 6 to not mislead people into thinking that pure
>>> frontend / pure SPA solutions are inherently less safe than cookie-based
>>> approaches.
>>> - generally focusing on documenting attacks and countermeasures, as
>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics is
>>> doing quite well :-)
>>>
>>> How can we improve the current situation? Would it be useful to list and
>>> detail some attacks that are not documented in the *OAuth 2.0 Security
>>> Best Current Practice* document? Would submitting a new draft for
>>> frontends be a good idea?
>>>
>>> Best regards,
>>>
>>> Yannick Majoros
>>>
>>> Le mer. 15 juin 2022 à 04:11, Dick Hardt  a
>>> écrit :
>>>
>>>>
>>>>
>>>> Best practices according to whom?
>>>>
>>>>
>>>> This list, and documents such as:
>>>> https://datatracker.ietf.or

Re: [OAUTH-WG] questions around OAuth 2.0 for Browser-Based Apps

[Aaron Parecki]

 Yannick Majoros 
>> wrote:
>>
>>> Hello Aaron and anyone in the group,
>>>
>>> Could you further comment on my last email?
>>>
>>> I'd have an additional question: in
>>> https://datatracker.ietf.org/doc/html/rfc6749#section-10 there is a
>>> list of security considerations. Wouldn't the concerns of section 6 of your
>>> draft better be parts of a follow-up or addendum to rfc-6749?
>>>
>>> Thanks,
>>>
>>> Yannick
>>>
>>>
>>> Le sam. 11 juin 2022 à 20:55, Yannick Majoros  a
>>> écrit :
>>>
>>>> >> There is a lot of debate around the question. Are these really
>>>> security best practices?
>>>> >The intent of this draft is to document the best practices today. If
>>>> >anything in the document is not the best way to do something given the
>>>> >documented constraints, then that should be revisited.
>>>>
>>>> Best practices according to whom? There are various opinions on the
>>>> subject, it's not black and white, so wouldn't it be best to be factual,
>>>> e.g. describing attack X and counter-measures, and how solution Y is the
>>>> best known tradeoff for that case.
>>>>
>>>> I indeed suggest section 6 to be revisited, as this the options
>>>> described there are neither universally agreed upon, neither the best/only
>>>> options to secure an application.
>>>>
>>>> I'd be happy to contribute, btw. I'm in the process of completing a
>>>> kind of matrix which associates all known options (BFF, local/session
>>>> storage/service worker/web worker/closure/token in a cookie/...), the
>>>> security issues involved and their impact. I do also have POCs and further
>>>> documentation for each solution, along with attack descriptions and their
>>>> mitigations.
>>>>
>>>> > Did you consider using a service worker or other frontend solutions
>>>> (web worker, closure...) for safe token storage? That would make a pure
>>>> frontend solution at least as safe as cookies.
>>>>
>>>> This has been on my list to write up as another option.
>>>>
>>>> Great. I'd be interested in providing input here. Would it be useful?
>>>>
>>>> >> What if the backend is stateless and so doesn't have any session
>>>> >You would need to use an encrypted session cookie to avoid storing
>>>> >server-side state, but this is available in many web frameworks.
>>>>
>>>> Isn't that encrypted session cookie a kind of token? :-) Is this a best
>>>> practice?
>>>>
>>>> Best regards,
>>>>
>>>> Yannick
>>>>
>>>> Le ven. 10 juin 2022 à 23:02, Aaron Parecki  a
>>>> écrit :
>>>>
>>>>> Hi Yannick, answers inline:
>>>>>
>>>>> > There is a lot of debate around the question. Are these really
>>>>> security best practices?
>>>>>
>>>>> The intent of this draft is to document the best practices today. If
>>>>> anything in the document is not the best way to do something given the
>>>>> documented constraints, then that should be revisited.
>>>>>
>>>>> > Did you consider using a service worker or other frontend solutions
>>>>> (web worker, closure...) for safe token storage? That would make a pure
>>>>> frontend solution at least as safe as cookies.
>>>>>
>>>>> This has been on my list to write up as another option.
>>>>>
>>>>> > Why would a cookie be safer, as this opens CSRF attacks that would
>>>>> make the same actions available to a hacker that would be possible by
>>>>> getting hold of a token (which might even be more difficult)?
>>>>>
>>>>> The assumption is that you would also protect against CSRF attacks
>>>>> like any typical web application.
>>>>>
>>>>> > What if the backend is stateless and so doesn't have any session
>>>>>
>>>>> You would need to use an encrypted session cookie to avoid storing
>>>>> server-side state, but this is available in many web frameworks.
>>>>>
>>>>> Aaron
>>>>>
>>>>>
>>>>> On Fri, Jun 10, 2022 at 5:12 AM Yannick Maj

Re: [OAUTH-WG] questions around OAuth 2.0 for Browser-Based Apps

[Aaron Parecki]

Hi Yannick, answers inline:

> There is a lot of debate around the question. Are these really security best 
> practices?

The intent of this draft is to document the best practices today. If
anything in the document is not the best way to do something given the
documented constraints, then that should be revisited.

> Did you consider using a service worker or other frontend solutions (web 
> worker, closure...) for safe token storage? That would make a pure frontend 
> solution at least as safe as cookies.

This has been on my list to write up as another option.

> Why would a cookie be safer, as this opens CSRF attacks that would make the 
> same actions available to a hacker that would be possible by getting hold of 
> a token (which might even be more difficult)?

The assumption is that you would also protect against CSRF attacks
like any typical web application.

> What if the backend is stateless and so doesn't have any session

You would need to use an encrypted session cookie to avoid storing
server-side state, but this is available in many web frameworks.

Aaron


On Fri, Jun 10, 2022 at 5:12 AM Yannick Majoros  wrote:
>
> Hello,
>
> Regarding "OAuth 2.0 for Browser-Based Apps" section 6 ( 
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-09#section-6
>  ), I do have some questions and concerns. Can I get in touch with someone 
> about this?
>
> My main questions are:
> - There is a lot of debate around the question. Are these really security 
> best practices?
> - Did you consider using a service worker or other frontend solutions (web 
> worker, closure...) for safe token storage? That would make a pure frontend 
> solution at least as safe as cookies.
> - Why would a cookie be safer, as this opens CSRF attacks that would make the 
> same actions available to a hacker that would be possible by getting hold of 
> a token (which might even be more difficult)?
> - What if the backend is stateless and so doesn't have any session (which 
> defeats 6.1 & 6.2 and leaves no option according to current draf)?
>
> Best regards.
>
> Yannick Majoros
> Valuya sprl
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.1 Sections 4.1.2.1. Error Response (Authorization Endpoint) and 5.2. Error Response (Token Endpoint)

[Aaron Parecki]

I see how this could be confusing, so I'll make a note to clarify it.
However, the only two error codes that would be returned from the
authorization endpoint would be HTTP 200 or 302, because this is always
returned to the browser, not to the OAuth client.

In the case of the authorization server communicating the error to the
user, that would be HTTP 200 so that their browser will render the page
rather than show its own error.

In the case of the authorization server communicating the error to the
client, it would of course have to send HTTP 302 so that the browser is
redirected to the client.

I do see the HTTP 302 included as an example in 4.1.2.1 but I agree this
could be made more explicit, thanks!

Aaron


On Sat, Feb 12, 2022 at 6:50 PM  wrote:

> Section 5.2. Error Response for the Token Endpoint states:
>
>
>
> The authorization server responds with an HTTP 400 (Bad Request)
>
> status code (unless specified otherwise) and includes the following
>
> parameters with the response:
>
>
> "error":  REQUIRED.  A single ASCII [USASCII 
> ] 
> error code from the
>
> Following:
>
>
> (error list omitted for breviate)
>
>
>
> Section 4.1.2.1. Error Response for the Authorization Endpoint contains the
>
> Same error list but no direction about what HTTP status code should be 
> returned.
> Wouldn’t it be helpful in the OAuth 2.1 draft to enhance section 4.1.2.1. 
> Error
>
> Response with the same or similar guidance regarding the current HTTP status 
> code
>
> to return?
>
>
>
>
>
>
>
> Best regards,
>
> Don
>
> Donald F. Coffin
>
> Founder/CTO
>
>
>
> REMI Networks
>
> 2335 Dunwoody Crossing Suite E
>
> Dunwoody, GA 30338-8221
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Aaron Parecki]

That doesn't have the literal string "S256", only the full name.


On Fri, Feb 4, 2022 at 6:02 PM Brian Campbell  wrote:

> I think
> https://www.iana.org/assignments/named-information/named-information.xhtml
> maybe has what you're looking for.
>
> On Fri, Feb 4, 2022, 6:33 PM Mike Jones  40microsoft@dmarc.ietf.org> wrote:
>
>> Kristina and I spoke about it today and we agreed that it makes sense to
>> make the hash algorithm explicit.  So for instance, we’d propose that the
>> example
>>
>>
>> urn:ietf:params:oauth:jwk-thumbprint:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
>>
>> become
>>
>>
>> urn:ietf:params:oauth:jwk-thumbprint:S256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
>>
>> when using the SHA-256 hash function.
>>
>>
>>
>> Similarly, we’d propose to also define S384, S512, and possibly also
>> S3-256, S3-384, and S3-512 (for the SHA-3 hash functions).
>>
>>
>>
>> For extra credit, if there’s already an IANA registry with string names
>> for these hash functions, we’d consider using it.  I looked for one and
>> surprisingly didn’t find it.  Or we could create one.
>>
>>
>>
>>Thanks all,
>>
>>-- Mike & Kristina
>>
>>
>>
>> *From:* OAuth  *On Behalf Of * Mike Jones
>> *Sent:* Friday, February 4, 2022 7:30 AM
>> *To:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Re: WGLC for JWK Thumbprint URI document
>>
>>
>>
>> Neil, thanks for your review.  First, you wrote:
>>
>>
>>
>> > Using a (hash of a) public key as an identifier is an idea that has
>> historically been subject to various attacks such as unknown key share
>> attacks, as well as issues due to malleable signature schemes or key
>> exchange schemes - where the same proof of identity is valid under many
>> public keys. The security considerations should mention these issues, and
>> potential suggest countermeasures (eg including the full public key JWK in
>> the input to be signed etc).
>>
>>
>>
>> I’m not all that familiar with the attacks you’re referencing.  Is there
>> I write-up on them that you could refer me and the other working group
>> members to so we can better understand them?  And ideally, could you write
>> up a paragraph or two on them that you’d like us to include in the Security
>> Considerations?
>>
>>
>>
>> Second, you asked that the hash algorithm be made explicit, as did
>> Vladimir.  I’ll consult with Kristina on that today and respond to that
>> suggestion in a subsequent message.
>>
>>
>>
>>Thanks again,
>>
>>-- Mike
>>
>>
>>
>> *From:* OAuth  *On Behalf Of *Vladimir Dzhuvinov
>> *Sent:* Thursday, February 3, 2022 11:00 PM
>> *To:* oauth@ietf.org
>> *Subject:* [EXTERNAL] Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document
>>
>>
>>
>> The original JWK thumbprint RFC 7638 essentially describes the method for
>> composing the hash input from a JWK and that the output is base64url
>> encoded. SHA-256 is mentioned, but there is no default implied hash
>> function. This leaves it to applications / other specs to determine.
>>
>> https://www.rfc-editor.org/rfc/rfc7638.html#section-3.4
>>
>> The URN gives us now a natural possibility to encode the hash function
>> alongside the fact that it's a JWK thumbprint, so let's include it. This
>> will make things more explicit and self-contained.
>>
>> What do the authors think about this possibility?
>>
>> ~Vladimir
>>
>> Vladimir Dzhuvinov
>>
>> On 04/02/2022 01:47, Neil Madden wrote:
>>
>> The draft doesn’t specify which hash function is being used. I assume it
>> is SHA-256, but it should either say that is the only algorithm allowed or
>> perhaps encode the hash algorithm into the URI. Otherwise the value is
>> ambiguous.
>>
>>
>>
>> Using a (hash of a) public key as an identifier is an idea that has
>> historically been subject to various attacks such as unknown key share
>> attacks, as well as issues due to malleable signature schemes or key
>> exchange schemes - where the same proof of identity is valid under many
>> public keys. The security considerations should mention these issues, and
>> potential suggest countermeasures (eg including the full public key JWK in
>> the input to be signed etc).
>>
>>
>>
>> — Neil
>>
>>
>>
>> On 2 Feb 2022, at 12:19, Rifaat Shekh-Yusef 
>>  wrote:
>>
>> 
>>
>> All,
>>
>>
>>
>> The *JWK Thumbprint URI *document is a simple and
>> straightforward specification.
>>
>>
>>
>> This is a WG Last Call for this document:
>>
>>
>> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html
>>
>>
>>
>> Please, provide your feedback on the mailing list by *Feb 16th*.
>>
>>
>>
>> Regards,
>>
>>  Rifaat & Hannes
>>
>>
>>
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> 

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Aaron Parecki]

I don't think this is actually the best place to reference, but S256
already exists in the registry established by RFC7636 (PKCE):

https://datatracker.ietf.org/doc/html/rfc7636#section-6.2
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#pkce-code-challenge-method

The other place these similar strings appear are FIDO, which also
references PKCE for the naming convention:

https://fidoalliance.org/specs/fido-v2.0-ps-20150904/fido-signature-format-v2.0-ps-20150904.html#iana-considerations

I thought I had remembered these strings being defined somewhere in NIST,
but I can't find that reference anymore.

Maybe it does make sense to establish this registry in the OAuth WG that
could be referenced by any related spec that needs them? OAuth 2.1 could
reference it as well.

Aaron



On Fri, Feb 4, 2022 at 5:33 PM Mike Jones  wrote:

> Kristina and I spoke about it today and we agreed that it makes sense to
> make the hash algorithm explicit.  So for instance, we’d propose that the
> example
>
>
> urn:ietf:params:oauth:jwk-thumbprint:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
>
> become
>
>
> urn:ietf:params:oauth:jwk-thumbprint:S256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
>
> when using the SHA-256 hash function.
>
>
>
> Similarly, we’d propose to also define S384, S512, and possibly also
> S3-256, S3-384, and S3-512 (for the SHA-3 hash functions).
>
>
>
> For extra credit, if there’s already an IANA registry with string names
> for these hash functions, we’d consider using it.  I looked for one and
> surprisingly didn’t find it.  Or we could create one.
>
>
>
>Thanks all,
>
>-- Mike & Kristina
>
>
>
> *From:* OAuth  *On Behalf Of * Mike Jones
> *Sent:* Friday, February 4, 2022 7:30 AM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Re: WGLC for JWK Thumbprint URI document
>
>
>
> Neil, thanks for your review.  First, you wrote:
>
>
>
> > Using a (hash of a) public key as an identifier is an idea that has
> historically been subject to various attacks such as unknown key share
> attacks, as well as issues due to malleable signature schemes or key
> exchange schemes - where the same proof of identity is valid under many
> public keys. The security considerations should mention these issues, and
> potential suggest countermeasures (eg including the full public key JWK in
> the input to be signed etc).
>
>
>
> I’m not all that familiar with the attacks you’re referencing.  Is there I
> write-up on them that you could refer me and the other working group
> members to so we can better understand them?  And ideally, could you write
> up a paragraph or two on them that you’d like us to include in the Security
> Considerations?
>
>
>
> Second, you asked that the hash algorithm be made explicit, as did
> Vladimir.  I’ll consult with Kristina on that today and respond to that
> suggestion in a subsequent message.
>
>
>
>Thanks again,
>
>-- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *Vladimir Dzhuvinov
> *Sent:* Thursday, February 3, 2022 11:00 PM
> *To:* oauth@ietf.org
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document
>
>
>
> The original JWK thumbprint RFC 7638 essentially describes the method for
> composing the hash input from a JWK and that the output is base64url
> encoded. SHA-256 is mentioned, but there is no default implied hash
> function. This leaves it to applications / other specs to determine.
>
> https://www.rfc-editor.org/rfc/rfc7638.html#section-3.4
>
> The URN gives us now a natural possibility to encode the hash function
> alongside the fact that it's a JWK thumbprint, so let's include it. This
> will make things more explicit and self-contained.
>
> What do the authors think about this possibility?
>
> ~Vladimir
>
> Vladimir Dzhuvinov
>
> On 04/02/2022 01:47, Neil Madden wrote:
>
> The draft doesn’t specify which hash function is being used. I assume it
> is SHA-256, but it should either say that is the only algorithm allowed or
> perhaps encode the hash algorithm into the URI. Otherwise the value is
> ambiguous.
>
>
>
> Using a (hash of a) public key as an identifier is an idea that has
> historically been subject to various attacks such as unknown key share
> attacks, as well as issues due to malleable signature schemes or key
> exchange schemes - where the same proof of identity is valid under many
> public keys. The security considerations should mention these issues, and
> potential suggest countermeasures (eg including the full public key JWK in
> the input to be signed etc).
>
>
>
> — Neil
>
>
>
> On 2 Feb 2022, at 12:19, Rifaat Shekh-Yusef 
>  wrote:
>
> 
>
> All,
>
>
>
> The *JWK Thumbprint URI *document is a simple and
> straightforward specification.
>
>
>
> This is a WG Last Call for this document:
>
> 

Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

[Aaron Parecki]

use would be perfectly implemented.
>>
>>
>>
>> However, in practice these artefacts do find their way into log files in
>> various places and one-time use may not always be practical (e.g. one-time
>> use in a certain timeframe etc).
>>
>>
>>
>> The addition of these mitigations is not meant to replace the need for
>> one-time use or good logging hygiene. Instead they provide pragmatic
>> defence in depth against real attacks rather than assuming perfect
>> implementations. We are deploying these mitigations and are sharing them
>> for inclusion in DPoP to enable others to do the same.
>>
>>
>>
>> Regarding the question about interrupting/intercepting the HTTPS
>> connection, the attacker don’t need to intercept the HTTPS connection or
>> modify the content in the TLS tunnel, rather they just need to prevent the
>> authorization code from being presented to the Authorization Server. It may
>> even happen due to a poor network connection. The poor connection may be
>> engineered by an attacker, or they may opportunistically benefit from it.
>> The networks are not perfect either.
>>
>>
>>
>> Cheers
>>
>>
>>
>> Pieter
>>
>>
>>
>>
>>
>> *From:* OAuth  *On Behalf Of *Aaron Parecki
>> *Sent:* Wednesday 1 December 2021 00:05
>> *To:* Neil Madden 
>> *Cc:* Mike Jones ;
>> oauth@ietf.org
>> *Subject:* [EXTERNAL] Re: [OAUTH-WG] dpop_jkt Authorization Request
>> Parameter
>>
>>
>>
>> I tend to agree with Neil here. I'm struggling to see the relevance of
>> this attack.
>>
>>
>>
>> It seems like the PDF writeup describes two possible reasons an attacker
>> could get access to the authorization code and PKCE code verifier.
>>
>>
>>
>> 1. The attacker has access to the logs of the token endpoint.
>>
>> 2. The attacker can intercept HTTPS connections between the client and AS
>> (VPN, corporate network proxy, etc)
>>
>>
>>
>> For 1, the solution is to stop logging the contents of the POST body, and
>> secure your infrastructure. I don't think making the client jump through
>> extra hoops is a good solution if you are already logging more than you
>> should be or you don't trust the people who have access to the
>> infrastructure. If this really is a concern, I suspect there are a lot more
>> places in the flow that would need to be patched up if you don't trust your
>> own token endpoint.
>>
>>
>>
>> For 2, if the attacker can intercept the HTTPS connection, then the
>> proposed solution doesn't add anything because the attacker could modify
>> the requests before it hits the authorization server anyway, and change
>> which DPoP key the token gets bound to in the first place. Plus, the
>> attacker would also have access to anything else the client is sending to
>> the AS, such as the user's password when they authenticate at the AS.
>>
>>
>>
>> Are there other attack vectors I'm missing that might actually be solved
>> by this mechanism?
>>
>>
>>
>> Aaron
>>
>>
>>
>>
>>
>> On Tue, Nov 30, 2021 at 12:40 PM Neil Madden 
>> wrote:
>>
>> Sadly I couldn’t make the DPoP session, but I’m not convinced the attack
>> described in the earlier message really needs to be prevented at all. The
>> attack largely hinges on auth codes not being one-time use, which is not a
>> good idea, or otherwise on poor network security on the token endpoint. I’m
>> not convinced DPoP needs to protect against these things. Is there more to
>> this?
>>
>>
>>
>> The proposed solutions also seem susceptible to the same problems they
>> attempt to solve - if an attacker is somehow able to interrupt the client’s
>> (TLS-protected) token request, why are they somehow not able to
>> interrupt/modify the (far less protected) redirect to the authorization
>> endpoint?
>>
>>
>>
>> — Neil
>>
>>
>>
>> On 30 Nov 2021, at 20:15, Mike Jones <
>> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>>
>>
>>
>> As described during the OAuth Security Workshop session on DPoP, I
>> created a pull request adding the dpop_jkt authorization request parameter
>> to use for binding the authorization code to the client’s DPoP key.  See
>> https://github.com/danielfett/draft-dpop/pull/89
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdanielfett%2Fdraft-dpop%2Fpull%2F89=

Re: [OAUTH-WG] dpop_jkt Authorization Request Parameter

[Aaron Parecki]

I tend to agree with Neil here. I'm struggling to see the relevance of this
attack.

It seems like the PDF writeup describes two possible reasons an attacker
could get access to the authorization code and PKCE code verifier.

1. The attacker has access to the logs of the token endpoint.
2. The attacker can intercept HTTPS connections between the client and AS
(VPN, corporate network proxy, etc)

For 1, the solution is to stop logging the contents of the POST body, and
secure your infrastructure. I don't think making the client jump through
extra hoops is a good solution if you are already logging more than you
should be or you don't trust the people who have access to the
infrastructure. If this really is a concern, I suspect there are a lot more
places in the flow that would need to be patched up if you don't trust your
own token endpoint.

For 2, if the attacker can intercept the HTTPS connection, then the
proposed solution doesn't add anything because the attacker could modify
the requests before it hits the authorization server anyway, and change
which DPoP key the token gets bound to in the first place. Plus, the
attacker would also have access to anything else the client is sending to
the AS, such as the user's password when they authenticate at the AS.

Are there other attack vectors I'm missing that might actually be solved by
this mechanism?

Aaron


On Tue, Nov 30, 2021 at 12:40 PM Neil Madden 
wrote:

> Sadly I couldn’t make the DPoP session, but I’m not convinced the attack
> described in the earlier message really needs to be prevented at all. The
> attack largely hinges on auth codes not being one-time use, which is not a
> good idea, or otherwise on poor network security on the token endpoint. I’m
> not convinced DPoP needs to protect against these things. Is there more to
> this?
>
> The proposed solutions also seem susceptible to the same problems they
> attempt to solve - if an attacker is somehow able to interrupt the client’s
> (TLS-protected) token request, why are they somehow not able to
> interrupt/modify the (far less protected) redirect to the authorization
> endpoint?
>
> — Neil
>
> On 30 Nov 2021, at 20:15, Mike Jones <
> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>
> As described during the OAuth Security Workshop session on DPoP, I created
> a pull request adding the dpop_jkt authorization request parameter to use
> for binding the authorization code to the client’s DPoP key.  See
> https://github.com/danielfett/draft-dpop/pull/89.
>
> This is an alternative to https://github.com/danielfett/draft-dpop/pull/86,
> which achieved this binding using a new DPoP PKCE method.  Using this
> alternative allows PKCE implementations to be unmodified, while adding DPoP
> in new code, which may be an advantage in some deployments.
>
> Please review and comment.  Note that I plan to add more of the attack
> description written by Pieter Kasselman to the security considerations in a
> future commit.  This attack description was sent by Pieter yesterday in a
> message with the subject “Authorization Code Log File Attack (was DPoP
> Interim Meeting Minutes)”.
>
>-- Mike
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [EXTERNAL] Rotating RTs and grace periods

[Aaron Parecki]

The grace period is not about the refresh token lifetime, it's specifically
about whether what would be a single-use refresh token can be used more
than one time within a short window of the first use.

Okta supports a configurable grace period per application that the customer
can set, anywhere from 0 to 60 seconds.

Personally I also agree with Neil that a grace period is not a good idea
from the security aspect, but I do also see that we have a lot of customers
who ask for this feature due to things like flaky mobile networks.

I like the suggested text from Neil. I assume this would go into the
Security BCP as well as OAuth 2.1?

Aaron


On Tue, Nov 2, 2021 at 7:09 AM Pieter Kasselman  wrote:

> Neil
>
>
>
> Is the goal to accommodate network latency or clock drift? It would be
> helpful to include reasons for why a grace period should be considered if
> it is allowed.
>
>
>
> Without knowing the reasons for the grace period it is not clear why a
> grace period is a better solution than just extending the expiry time by a
> set time (60 seconds in your example) and having the client present the
> token a little earlier.
>
>
>
> If grace periods are allowed, it may be worth considering adding
> additional mitigations against replay. For example, a grace period may be
> allowed if the refresh token is sender constrained with DPoP so there is at
> least some assurances that the request is originating from the sender
> (especially if the nonce option is used with DPoP).
>
>
>
> I would worry about adding more complexity and less predictability by
> adding grace periods though (e.g. by looking at a refresh token, will you
> be able to tell if it can still be used or not), but your point that
> implementors may solve for it in other less predictable ways raises a valid
> point.
>
>
>
> Cheers
>
>
>
> Pieter
>
>
>
> *From:* OAuth  *On Behalf Of *Neil Madden
> *Sent:* Tuesday 2 November 2021 10:29
> *To:* oauth 
> *Subject:* [EXTERNAL] [OAUTH-WG] Rotating RTs and grace periods
>
>
>
> Hi all,
>
>
>
> There was a previous discussion on whether to allow a grace period during
> refresh token rotation, allowing the client to retry a refresh if the
> response fails to be received due to some transient network issue/timeout
> [1]. Vittorio mentioned that Auth0 already implement such a grace period.
> We (ForgeRock) currently do not, but we do periodically receive requests to
> support this. The current security BCP draft is silent on whether
> implementing such a grace period is a good idea, but I think we should add
> some guidance here one way or another.
>
>
>
> My own opinion is that a grace period is not a good idea, and if it is to
> be supported as an option then it should be kept as short as possible. The
> reason (as I mentioned in the previous thread) is that it is quite easy for
> an attacker to observe when a legitimate client performs a refresh flow and
> so can easily sneak in their own request afterwards within the grace
> period. There are several reasons why it is easy for an attacker to observe
> this:
>
>
>
> - RT rotation is primarily intended for public clients, such as mobile
> apps and SPAs. These clients are geographically distributed across the
> internet, and so there is a good chance that the attacker is able to
> observe the network traffic of at least some of these client instances.
>
> - The refresh flow is typically the only request that the client makes
> directly to the AS after initial authorization, so despite the traffic
> being encrypted it is very easy for an observer to determine that the
> client is performing a refresh whenever it makes any connection to the AS.
>
> - As well as observing the request itself, an attacker may be able to
> observe the DNS lookup for the AS hostname instead, which is even more
> likely to be observable and also in plaintext most of the time.
>
> - An attacker in a position to steal RTs from e.g. localStorage, is
> probably also in a good position to either observe when the legitimate
> client refreshes or to actually force it to refresh early (e.g., by
> deleting the corresponding AT from the same storage).
>
>
>
> I know some people argue that a grace period is a reasonable trade-off
> between security and usability. But I think that this kind of attack would
> be quite easy to carry out in practice for the reasons I suggest above, so
> I think the security actually degrades extremely quickly if you allow a
> grace period of any reasonable length.
>
>
>
> On the other hand, if we discourage this entirely then people may use
> dubious workarounds instead (e.g., one proposal I’ve seen was to use an ID
> token with the JWT Bearer grant, effectively turning the ID Token into an
> ad-hoc RT with much fewer protections).
>
>
>
> As a strawman, what would people think of wording like the following:
>
>
>
> ---
>
> The AS MAY allow the original RT to be replayed for a short grace period
> to allow the client to recover if the response is not received 

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

[Aaron Parecki]

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 <
pieter.kassel...@microsoft.com> 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  *On Behalf Of *Sascha Preibisch
> *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
> 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  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 <
> saschapreibi...@gmail.com> 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  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  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?
>
>
> *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=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293904430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=vwcfj%2FVB8a84yDoAmqkXraWyqjOfWGrV08XdtZLWMXw%3D=0>
> .
>
>
>
>
>
> On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki  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 <
> pieter.kassel...@microsoft.com> 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 

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

[Aaron Parecki]

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 
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  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  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?
>>>
>>> Warren Parad
>>>
>>> Founder, CTO
>>> Secure your user data with IAM authorization as a service. Implement
>>> Authress <https://authress.io/>.
>>>
>>>
>>> On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki 
>>> 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 <
>>>> pieter.kassel...@microsoft.com> 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  *On Behalf Of *Aaron Parecki
>>>>> *Sent:* Wednesday 13 October 2021 18:40
>>>>> *To:* Warren Parad 
>>>>> *Cc:* Mike Jones ;
>>>>> oauth@ietf.org
>>>>> *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 >>>> 40rhosys...@dmarc.ietf.org> wrote:
>>>>>
>&

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

[Aaron Parecki]

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?
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress <https://authress.io/>.
>
>
> On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki  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 <
>> pieter.kassel...@microsoft.com> 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  *On Behalf Of *Aaron Parecki
>>> *Sent:* Wednesday 13 October 2021 18:40
>>> *To:* Warren Parad 
>>> *Cc:* Mike Jones ;
>>> oauth@ietf.org
>>> *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 >> 40rhosys...@dmarc.ietf.org> 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".
>>&g

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

[Aaron Parecki]

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 <
pieter.kassel...@microsoft.com> 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  *On Behalf Of *Aaron Parecki
> *Sent:* Wednesday 13 October 2021 18:40
> *To:* Warren Parad 
> *Cc:* Mike Jones ;
> oauth@ietf.org
> *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  40rhosys...@dmarc.ietf.org> 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"?
>
>
>
> *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=04%7C01%7Cpieter.kasselman%40microsoft.com%7C64289cdc8a4743659b3108d98e70a5d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697436788333255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=lw%2BH1z1Ut9kr6S%2F4aVsPmcErAcZx0eK2WV78OlEl2dU%3D=0>
> .
>
>
>
>
>
> On Wed, Oct 13, 2021 at 7:17 PM Mike Jones  40microsoft@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 authorizati

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

[Aaron Parecki]

PKCE is built in to the authorization code flow in OAuth 2.1 and does not
depend on the client type.

Neil does bring up a good point about the "plain" challenge type though.
The "plain" type does undermine some of the security guarantees that PKCE
provides. The Security BCP does recommend against using the "plain" type
but that may not be enough confidence to rely on this mechanism and give up
others.

Aaron



On Wed, Oct 13, 2021 at 11:02 AM Warren Parad  wrote:

> Thanks Aaron, that's a great point. In light of that, I would ask about
> the recommendation for non-SPA. I was under the impression that non-SPA's
> don't require the use of PKCE, which would make them vulnerable to replay
> attacks. Or am I missing something?
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress <https://authress.io/>.
>
>
> On Wed, Oct 13, 2021 at 7:59 PM Neil Madden 
> wrote:
>
>> I wasn’t on the call either, so maybe I’m missing something. If you’re
>> using PKCE with the “plain” challenge type then both the auth code and the
>> verifier are exposed in redirect URI parameters in the user-agent aren’t
>> they? That seems a bit risky to drop the one-time use requirement.
>>
>> I can’t see anything in the minutes of the meeting describing the
>> difficulty of implementing the one-time use req. I seem to see
>> announcements for new globally-consistent high-scale cloud database
>> services every day - is this really that hard to implement?
>>
>> — Neil
>>
>> On 13 Oct 2021, at 18:41, Aaron Parecki  wrote:
>>
>> 
>> 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 > 40rhosys...@dmarc.ietf.org> 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"?
>>>
>>>
>>> Warren Parad
>>>
>>> Founder, CTO
>>> Secure your user data with IAM authorization as a service. Implement
>>> Authress <https://authress.io/>.
>>>
>>>
>>> On Wed, Oct 13, 2021 at 7:17 PM Mike Jones >> 40microsoft@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
>>>>
>>

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

[Aaron Parecki]

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  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"?
>
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress <https://authress.io/>.
>
>
> On Wed, Oct 13, 2021 at 7:17 PM Mike Jones  40microsoft@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
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Aaron Parecki]

> obviously we can't use any sensitive keys with these

That's not true at all, public clients can use keys that they create
themselves or are issued to a particular instance. That's one of the
reasons we are giving a name to this type of client in OAuth 2.1, a
"credentialed" client.

A public client clearly can't share credentials with other instances of the
public client, but there's no reason they can't use a key that is only ever
known to them.




On Thu, Oct 7, 2021 at 9:06 PM Ash Narayanan 
wrote:

> Oh geez, yesterday was my day off but ended up down a deep rabbit hole
> after reading this draft and the ones that came before it.
>
> I do not support adoption and was going to list my reasons but Warren
> Parad beat me to it.
>
> In addition to the list he has provided, I'd also like to see the draft
> make a mention of public clients; obviously we can't use any sensitive keys
> with these.
>
>
> Regards,
> Ash
>
> On Thu, Oct 7, 2021 at 11:02 PM Neil Madden 
> wrote:
>
>> Canonicalised signature schemes inevitably lead to cryptographic doom,
>> and should die with SAML (ha!). For that reason I do not support adoption
>> of this draft.
>>
>> I also think the arguments for canonicalisation vanish as soon as you
>> want end-to-end confidentiality too.
>>
>> — Neil
>>
>> On 6 Oct 2021, at 22:02, Rifaat Shekh-Yusef 
>> wrote:
>>
>> 
>> All,
>>
>> As a followup on the interim meeting today, this is a *call for adoption
>> *for the *OAuth Proof of Possession Tokens with HTTP Message Signature* draft
>> as a WG document:
>> https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/
>>
>> Please, provide your feedback on the mailing list by* October 20th*.
>>
>> Regards,
>>  Rifaat & Hannes
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> Manage My Preferences <https://preferences.forgerock.com/>, Unsubscribe
>> <https://preferences.forgerock.com/>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-1-04.txt

[Aaron Parecki]

Hello all, on Tuesday we published a new revision of the OAuth 2.1 draft in
advance of the interim meeting next week.

The main changes are documented in the changelog section but are summarized
below as well:

* Added explicit mention of not sending access tokens in URI query strings
* Clarifications on definition of client types
* Consolidated text around loopback vs localhost
* Editorial clarifications throughout the document

There are still a number of outstanding issues we are aware of, and have
highlighted a few of them for discussion during the session next week.

Aaron


On Tue, Oct 5, 2021 at 5:19 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
> Title   : The OAuth 2.1 Authorization Framework
> Authors : Dick Hardt
>           Aaron Parecki
>   Torsten Lodderstedt
> Filename: draft-ietf-oauth-v2-1-04.txt
> Pages   : 85
> Date: 2021-10-05
>
> Abstract:
>The OAuth 2.1 authorization framework enables a third-party
>application to obtain limited access to an HTTP service, either on
>behalf of a resource owner by orchestrating an approval interaction
>between the resource owner and an authorization service, or by
>allowing the third-party application to obtain access on its own
>behalf.  This specification replaces and obsoletes the OAuth 2.0
>Authorization Framework described in RFC 6749.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-1-04
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Aaron Parecki]

This actually seems like a great time for the OAuth group to start working
on this more closely given the relative stability of this draft as well as
the fact that it is not yet an RFC. This is a perfect time to be able to
influence the draft if needed, rather than wait for it to be finalized and
then have to find a less-than-ideal workaround for something unforeseen.

Aaron

On Wed, Oct 6, 2021 at 2:25 PM Dick Hardt  wrote:

> I meant it is not yet adopted as an RFC.
>
> To be clear, I think you are doing great work on the HTTP Sig doc, and a
> number of concerns I have with HTTP signing have been addressed => I just
> think that doing work in the OAuth WG on a moving and unproven draft in the
> HTTP WG is not a good use of resources in the OAuth WG at this time.
>
>
> ᐧ
>
> On Wed, Oct 6, 2021 at 2:20 PM Justin Richer  wrote:
>
>> > HTTP Sig looks very promising, but it has not been adopted as a draft
>>
>> Just to be clear, the HTTP Sig draft is an official adopted document of
>> the HTTP Working Group since about a year ago. I would not have suggested
>> we depend on it for a document within this WG otherwise.
>>
>>  — Justin
>>
>> On Oct 6, 2021, at 5:08 PM, Dick Hardt  wrote:
>>
>> I am not supportive of adoption of this document at this time.
>>
>> I am supportive of the concepts in the document. Building upon existing,
>> widely used, proven security mechanisms gives us better security.
>>
>> HTTP Sig looks very promising, but it has not been adopted as a draft,
>> and as far as I know, it is not widely deployed.
>>
>> We should wait to do work on extending HTTP Sig for OAuth until it has
>> stabilized and proven itself in the field. We have more than enough work to
>> do in the WG now, and having yet-another PoP mechanism is more likely to
>> confuse the community at this time.
>>
>> An argument to adopt the draft would be to ensure HTTP Sig can be used in
>> OAuth.
>> Given Justin and Annabelle are also part of the OAuth community, I'm sure
>> they will be considering how HTTP Sig can apply to OAuth, so the overlap is
>> serving us already.
>>
>> /Dick
>>
>>
>> ᐧ
>>
>> On Wed, Oct 6, 2021 at 2:04 PM Aaron Parecki  wrote:
>>
>>> I support adoption of this document.
>>>
>>> - Aaron
>>>
>>> On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef <
>>> rifaat.s.i...@gmail.com> wrote:
>>>
>>>> All,
>>>>
>>>> As a followup on the interim meeting today, this is a *call for
>>>> adoption *for the *OAuth Proof of Possession Tokens with HTTP Message
>>>> Signature* draft as a WG document:
>>>> https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/
>>>>
>>>> Please, provide your feedback on the mailing list by* October 20th*.
>>>>
>>>> Regards,
>>>>  Rifaat & Hannes
>>>>
>>>> ___
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Aaron Parecki]

I support adoption of this document.

- Aaron

On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> As a followup on the interim meeting today, this is a *call for adoption *for
> the *OAuth Proof of Possession Tokens with HTTP Message Signature* draft
> as a WG document:
> https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/
>
> Please, provide your feedback on the mailing list by* October 20th*.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-1-03.txt

[Aaron Parecki]

Hi all,

The editors have published a new draft of OAuth 2.1.

https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-03.html

Huge thanks to Vittorio Bertocci and Justin Richer for their previous
reviews of the draft, a large portion of the changes in this version are
based on their feedback.

Here is a high level summary of the changes from the previous draft:

* The major change is a refactoring to collect all the grant types under
the same top-level header in section 4:
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-03.html#name-grant-types
* Better split normative and security consideration text into the
appropriate places, both moving text that was really security
considerations out of the main part of the document, as well as pulling
normative requirements from the security considerations sections into the
appropriate part of the main document
* Incorporated many of the published errata on RFC6749
* Updated references to various RFCs
* Quite a lot of editorial clarifications throughout the document

We will continue to make progress on incorporating the suggestions from
previous reviews, but in the mean time, this was a significant structural
change that warranted publishing a new draft ahead of the upcoming interim
meetings. As always, feedback is greatly appreciated!

Thanks!

---
Aaron Parecki
https://aaronparecki.com
https://oauth2simplified.com



On Wed, Sep 8, 2021 at 2:06 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
> Title   : The OAuth 2.1 Authorization Framework
> Authors : Dick Hardt
>           Aaron Parecki
>   Torsten Lodderstedt
> Filename: draft-ietf-oauth-v2-1-03.txt
> Pages   : 86
> Date: 2021-09-08
>
> Abstract:
>The OAuth 2.1 authorization framework enables a third-party
>application to obtain limited access to an HTTP service, either on
>behalf of a resource owner by orchestrating an approval interaction
>between the resource owner and an authorization service, or by
>allowing the third-party application to obtain access on its own
>behalf.  This specification replaces and obsoletes the OAuth 2.0
>Authorization Framework described in RFC 6749.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-03.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-1-03
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Interim Meetings

[Aaron Parecki]

I would like to present on OAuth 2.1.

Separately, and preferably later in the series, I would like to present on
the Browser App BCP.

Thanks!

Aaron



On Sat, Sep 4, 2021 at 8:23 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> We would like to start a new series of interim meetings later in September.
> Please, let us know if you would like to present during one of
> these meetings.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - OAuth Proof of Possession Tokens with HTTP Message Signatures

[Aaron Parecki]

I support the adoption of this document, it seems like a good starting
point for defining the link between HTTP Signatures and OAuth.

Aaron


On Mon, Jul 19, 2021 at 7:18 AM Justin Richer  wrote:

> Needless to say, but as the author of both this draft and the draft that
> it would replace, I am in favor of adoption of this document. There are
> still a lot of open questions to answer — such as key introduction and
> management practices — and I think there is a lot of power in the
> intersection of the OAuth and HTTPSig spaces.
>
>  — Justin
>
> On Jul 16, 2021, at 12:31 PM, Rifaat Shekh-Yusef 
> wrote:
>
> All,
>
> This is a call for adoption for the *OAuth Proof of Possession Tokens
> with HTTP Message Signatures* draft as a WG document:
> https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/
>
> Please, provide your feedback on the mailing list *by July 30th*.
>
> Regards,
>  Rifaat & Hannes
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Can a client send the Authorization Request?

[Aaron Parecki]

Honestly it didn't even occur to me that someone would try this, since the
entire point of the authorization endpoint is that it's the thing the
user's browser talks to. Adding MTLS just means you're going to have to
send the user to some other endpoint instead, which is then effectively
acting as the authorization endpoint anyway. So yeah I could see adding
some language around the authorization endpoint needing to be accessible by
the user agent without MTLS or other funny stuff.

PAR also fits in nicely in that case since the PAR endpoint could be
protected with MTLS since it *is* intended to only be accessible from the
OAuth client.

Aaron

On Tue, May 25, 2021 at 4:38 PM Justin Richer  wrote:

> I'm actually wondering if we should add discussion about not putting mtls
> on the authorisation endpoint into OAuth 2.1. Aaron et al, thoughts?
>
> -Justin
> 
> From: A. Rothman [amich...@amichais.net]
> Sent: Tuesday, May 25, 2021 7:03 PM
> To: Justin Richer
> Cc: Sascha Preibisch; IETF oauth WG
> Subject: Re: [OAUTH-WG] Can a client send the Authorization Request?
>
> Justin,
>
> Thanks for this analysis. It pretty much sums up my own thoughts about
> this better than I could have :-)
>
> I just hope I wasn't 'leading the witness' too much... I'll have to
> double-check the details to make sure I didn't miss anything, but as I
> understand it, that's more or less it.
>
> btw it occurred to me that PAR wouldn't solve this specific problem either
> - if I understood correctly, it still ends with the user agent sending an
> Authorization Request to the AS, just with PAR-specific parameters instead
> of the usual ones... if so, and if the endpoint is still required to use
> mTLS, thus needs to be sent by the client... it would just be kicking the
> can down the road and violating the PAR spec instead.
>
> Thanks again for your time and explanations,
>
> Amichai
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] TMI BFF - html meta tags over/alternative to discovery

[Aaron Parecki]

Not exactly. The thinking is by standardizing these endpoints in some way,
it would allow client library developers to write generic libraries that
can work with any backend.


On Mon, May 17, 2021 at 1:53 PM Warren Parad  wrote:

> I can't follow the discussion. So I'm still missing why the endpoints
> would need to be listed anywhere. Isn't the developer of the html page, the
> same developer that will configure the HTTP request to go to the backend?
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress .
>
>
> On Mon, May 17, 2021 at 10:04 PM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> The interim discussion can be found here
>> https://codimd.ietf.org/s/notes-ietf-interim-2021-oauth-09-oauth#Discussion
>> but the general context, as I understand it, is that there's a desire to
>> have the location of the two application endpoints be conveyed to the
>> frontend in a defined way that avoids out-of-band configuration and also
>> doesn't infringe on the application namespace. The current draft places the
>> two endpoints directly in .well-known but a number of folks have stated
>> reasons that's less than ideal or even unworkable in many common
>> deployments. Moving to a single static document in .well-known that lists
>> the endpoint locations is one alternative approach. This thread suggests a
>> different alternative of placing the locations in HTML meta/link tags or
>> link headers returned with the application's main html page.
>>
>>
>> On Sun, May 16, 2021 at 2:04 AM Warren Parad > 40rhosys...@dmarc.ietf.org> wrote:
>>
>>> I agree, missing context for this:
>>>
>>> As discussed in the interim, a well known set of endpoints (or even a
>>> single root client discovery document) might not always be available for
>>> control to the webpage depending on where and how it is hosted, on the
>>> other hand the HTML it serves always, I hope, is.
>>>
>>> Wouldn't this only be used as input to a SDK, why wouldn't you just
>>> define the configuration in javascript, like everything else?
>>>
>>> Also, is it required or something that can be added later?
>>>
>>> On Sun, May 16, 2021, 09:26 Philippe De Ryck <
>>> phili...@pragmaticwebsecurity.com> wrote:
>>>
 Without having the full context of the interim meeting, this feels
 really off to me. I see the need for making this configurable, but I have
 doubts about using HTML elements for this purpose.

 As far as I understand, this mechanism is supposed to be used for
 modern frontends (Angular, React, …). Having to add variables to the
 index.html in these applications is likely to conflict with their
 development paradigms. It would be much easier to add these variables to
 the environment file, so you can differentiate between dev and prod when
 necessary.

 Additionally, querying the DOM for API endpoints sounds like a lot of
 trouble. I don’t think that injection is that big of a risk, but I might be
 wrong (I’m sure someone said that about the base tag as well). However,
 using DOM APIs like this will cause headaches for server-side rendering,
 where these DOM APIs are typically not available (e.g.,
 https://stackoverflow.com/questions/62896223/is-there-a-way-to-access-dom-serverside
 ).

 Kind regards

 Philippe

 —
 *Pragmatic Web Security*
 *Security for developers*
 https://pragmaticwebsecurity.com/


 On 15 May 2021, at 17:35, Filip Skokan  wrote:

 Hello Vittorio, Brian, everyone

 This is a followup to my feedback in the TMI BFF interim meeting on
 April 26th where I mentioned I'd bring this to the list for discussion.

 I proposed an alternative to using fixed endpoint locations and/or
 discovery. HTML  Tags
 .

 These would be in the returned page HTML's head tag, e.g.

 
> 


 The javascript SDK handing TMI BFF would know to look for these defined
 meta tags to source the location of the different endpoints. I think this
 could be the primary place an SDK would look at as it doesn't require any
 upfront external requests.

 For the SDK this is as simple as

 var bffTokenPath =
> document.querySelector('meta[name="oauth-bff-token"]').content;


 If this was the only mechanism defined by the document (to be bashed) I
 think it can save the group a lot of time defining a client discovery
 document which would be otherwise needed. If discovery as an alternative
 solution is indeed inevitable, it can be a second in line mechanism the
 javascript SDK would know to use.

 As discussed in the interim, a well known set of endpoints (or even a
 single root client discovery document) might not always be available for
 control to the webpage depending on 

Re: [OAUTH-WG] Reasoning behind OAuth 2.0 PKCE

[Aaron Parecki]

> If as mentioned in paragraph 4b. the source of the leak is the HTTP log
> of Authorization Request: why would not the attacker know the code
> verifier as well if Access Token Requests were logged too?

You're on the right track here. It's all about where the attacker is
sitting in the connection. PKCE isn't attempting to solve anything if there
is an attacker able observe the requests at the AS. It's about whether
there's an attacker between the client and AS.

The reason PKCE works here is that the PKCE code verifier never leaves the
client until the very last stage of exchanging the authorization code in an
HTTPS request directly to the token endpoint. That connection is assumed to
be secure since it is an HTTPS POST request. The attack PKCE prevents is
when the authorization code might be intercepted in the redirect from the
AS to the client, since that is *NOT* an HTTP/HTTPS request from the AS to
the client. That request is an HTTP redirect from the AS to the user agent,
and the user agent takes the authorization code and delivers it to the
client.

This distinction is the "front channel" vs "back channel". It comes up a
lot in the implicit flow discussions as well. I have some videos about the
implicit flow and general OAuth security that talk about this difference:

https://oauth.net/videos/

Hope this helps!

Aaron


On Tue, May 11, 2021 at 5:59 AM Marcin Szewczyk 
wrote:

> Hi,
>
> I am reading RFC 7636 (Proof Key for Code Exchange by OAuth Public
> Clients) to understand how it mitigates the problem of intercepting
> authorization code on the device itself and not in internet transit.
>
> I fail to understand reasoning behind the following paragraphs:
>
> 1. Introduction, 4b. (rephrased):
>
> the attacker observes both requests and responses to/from the
> authorization endpoint, not using MitM but http log of the OS
> leaking information (I presume URLs with parameters that ought to be
> secret)
>
> 1. Introduction, last paragraph:
>
> > The authorization code obtained is then sent to the token endpoint
> > with the "code verifier", and the server compares it with the
> > previously received request code so that it can perform the proof of
> > possession of the "code verifier" by the client. This works as the
> > mitigation since the attacker would not know this one-time key, since
> > it is sent over TLS and cannot be intercepted.
>
> I do not understand the remark about TLS here as TLS alone does not
> prevent the attack because the HTTP connection itself is not the source
> of the leak. It is even stated explicitly that it is not about MitM. I
> thought PKCE is all about TLS not being enough and leaking information
> in the OS. Without TLS at every step (in general) the whole scheme seems
> to fall apart.
>
> If as mentioned in paragraph 4b. the source of the leak is the HTTP log
> of Authorization Request: why would not the attacker know the code
> verifier as well if Access Token Requests were logged too?
>
> Is it assumed that Authorization Request is more susceptible to attack
> than Access Token Request because it is more probable that log will
> contain query parameters but not entity-body (request contents transfer
> methods respectively)?
>
> BTW, it may be impossible for the attacker to do a classic MitM but
> maybe the attacker could crash the legitimate application just after one
> gets the Access Token Request in log or just try to win the race or
> maybe replay Access Token Request?
>
> Additionally RFC 6750 (OAuth 2.0: Bearer Token Usage) allows sending
> bearer access tokens in URI query parameter so these URIs in log would
> pose danger as well. I suppose that is one of the reasons OAuth 2.0
> Security Best Current Practice[1] discourages this method.
>
> [1]:
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics
>
>
>
> The archive seems to contain mainly "internal" WG's discussions but
> maybe it is acceptable to ask the question here. I am sorry if it is
> not. I did not find a better place to ask.
>
> --
> Marcin Szewczyk
> http://wodny.org
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - TMI BFF

[Aaron Parecki]

Okay, I have come around to this idea and agree that we shouldn't use "BFF"
to refer to this pattern. The only reason I am continuing the discussion in
this thread is that if we agree we should avoid the term BFF for this
draft, I would like to see it renamed before it is adopted, to avoid any
confusion at the start.

Aaron


On Tue, May 4, 2021 at 10:28 AM Jim Manico  wrote:

> +1 Mr. Hardt. BFF aims to avoid access tokens in UA's so TMI-BFF is a
> badly branded name that will add confusion.
>
> - Jim
> On 5/4/21 11:25 AM, Dick Hardt wrote:
>
> My concern with BFF is that the common meaning is what the document calls
> Full BFF -- so what many readers will assume is BFF is not what the
> document is referring to.
> ᐧ
>
> On Tue, May 4, 2021 at 8:03 AM Aaron Parecki  wrote:
>
>> I support adoption. I'm also fine with the BFF acronym since it's common
>> in the software development world already. If anything, the TMI acronym is
>> the least strong of the two as it's missing a letter from the full name of
>> the draft.
>>
>> Aaron
>>
>>
>>
>>
>> On Tue, May 4, 2021 at 7:40 AM Dick Hardt  wrote:
>>
>>> I'm supportive -- but am concerned with the BFF acronym.
>>> ᐧ
>>>
>>> On Mon, May 3, 2021 at 3:00 PM Rifaat Shekh-Yusef <
>>> rifaat.s.i...@gmail.com> wrote:
>>>
>>>> All,
>>>>
>>>> This is a call for adoption for the *Token Mediating and Session
>>>> Information Backend for Frontend* as a WG document:
>>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/
>>>>
>>>> Please, provide your feedback on the mailing list by *May 17th*.
>>>>
>>>> Regards,
>>>>  Rifaat & Hannes
>>>> ___
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> --
>> ---
>> Aaron Parecki
>> https://aaronparecki.com
>>
>>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - TMI BFF

[Aaron Parecki]

I support adoption. I'm also fine with the BFF acronym since it's common in
the software development world already. If anything, the TMI acronym is the
least strong of the two as it's missing a letter from the full name of the
draft.

Aaron




On Tue, May 4, 2021 at 7:40 AM Dick Hardt  wrote:

> I'm supportive -- but am concerned with the BFF acronym.
> ᐧ
>
> On Mon, May 3, 2021 at 3:00 PM Rifaat Shekh-Yusef 
> wrote:
>
>> All,
>>
>> This is a call for adoption for the *Token Mediating and Session
>> Information Backend for Frontend* as a WG document:
>> https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/
>>
>> Please, provide your feedback on the mailing list by *May 17th*.
>>
>> Regards,
>>  Rifaat & Hannes
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token Mediating and session Information Backend For Frontend (TMI BFF)]

[Aaron Parecki]

 2/14/21 9:28 AM, Neil Madden wrote:
>>
>> Public clients are implicitly authenticated by their ownership of the 
>> registered redirect_uri. This why it’s important to use a redirect_uri for 
>> which ownership can be reasonably established, such as HTTPS endpoints with 
>> exact URI matching.
>>
>>
>>
>> There are more things that can go wrong with that (see the security BCP), 
>> but it can be made reasonably secure.
>>
>>
>>
>> — Neil
>>
>>
>>
>> On 14 Feb 2021, at 13:48, Stoycho Sleptsov  
>>  wrote:
>>
>>
>>
>> 
>>
>> I would like to add my reasons about the "Why are developers creating BFF 
>> for their frontends to communicate with an AS",
>>
>> with the objective to verify if they are valid.
>>
>>
>>
>> I need the client app. to be authenticated at the AS (to determine if it is 
>> a first-party app., for example).
>>
>> If we decide to implement our client as a frontend SPA , then we have no 
>> other option except through a BFF, as PKCE does not help for authentication.
>>
>>
>>
>> Or is it considered a bad practice to do that?
>>
>>
>>
>> Regards,
>>
>> Stoycho.
>>
>>
>> Sitz der Gesellschaft / Corporate Headquarters: Miles & More GmbH,
>> Frankfurt am Main, Registereintragung / Registration: Amtsgericht Frankfurt
>> am Main HRB 116409
>> Geschaeftsfuehrung / Management Board: Sebastian Riedle, Dr. Oliver
>> Schmitt
>>
>>
>> ___
>>
>> OAuth mailing list
>>
>> OAuth@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>
>>
>> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> --
>>
>> - Regards,
>> Omkar Khair
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> --
> Karsten Meyer zu Selhausen
> IT Security Consultant
> Phone:+49 (0)234 / 54456499
> Web:  https://hackmanit.de | IT Security Consulting, Penetration Testing, 
> Security Training
>
> Is your OAuth or OpenID Connect client vulnerable to the severe impacts of 
> mix-up attacks? Learn how to protect your client in our latest blog post on 
> single 
> sign-on:https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks
>
> Hackmanit GmbHUniversitätsstraße 60 
> <https://www.google.com/maps/search/Universit%C3%A4tsstra%C3%9Fe+60?entry=gmail=g>
>  (Exzenterhaus)
> 44789 Bochum
>
> Registergericht: Amtsgericht Bochum, HRB 14896
> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. 
> Christian Mainka, Dr. Marcus Niemietz
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

[Aaron Parecki]

> Do you disagree that this gives them control over which things talk to
their servers?

Yes -- with a public client, I can impersonate a "real" app and it's
basically non-detectable by the AS. For a theoretical example, if I wanted
to use the Instagram API but they restrict which apps can upload photos to
only their own mobile apps, I can find the client ID of their own app, then
do an OAuth flow using their own client ID, and without a client secret it
looks the same as their own client. I'm unlikely to be able to get
arbitrary users to authorize my app because of limits and checks on the
redirect URI, but I can certainly do it myself for my own account. This is
the sort of false sense of security provided by the client registration
step I'm talking about.

I'd love to solve the app identity problem too, but that's only possible
with cooperation from the mobile OSs.

Aaron

On Fri, Feb 26, 2021 at 1:36 PM David Waite 
wrote:

>
>
> > On Feb 26, 2021, at 9:32 AM, Aaron Parecki  wrote:
>
> > The point is that basically nobody uses it because they don't want to
> allow arbitrary client registration at their ASs. That's likely due to a
> combination of pre-registration being the default model in OAuth for so
> long (the Dynamic Client Registration draft was published several years
> after OAuth 2.0), as well as how large corporations have decided to run
> their ASs where they want to have (what feels like) more control over the
> things talking to their servers.
>
> Do you disagree that this gives them control over which things talk to
> their servers?
>
> FWIW my personal mental model here is pretty simple:
>
> With users, there are services you provide anonymously and services you
> provide only to registered/authenticated/trusted parties for various
> reasons. Once you are delegating user access, you still have many of the
> same reasons to provide access to anonymous or
> registered/authenticated/trusted delegates.
>
> Dynamic registration arriving later and requiring additional complexity
> has unfortunately encouraged registration in use cases where anonymous
> clients might have been acceptable, but shifting the timelines or
> complexity balance would not  have changed business needs for
> authentication and trust of delegates. Omitting registration would have
> caused businesses to use other protocols that met their needs.
>
> If AS’s are only getting what feels like proper control for their business
> needs, we should attempt to give them the actual control they require.
>
> -DW
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

[Aaron Parecki]

Dynamic client registration does exist in OAuth:
https://tools.ietf.org/html/rfc7591

The point is that basically nobody uses it because they don't want to allow
arbitrary client registration at their ASs. That's likely due to a
combination of pre-registration being the default model in OAuth for so
long (the Dynamic Client Registration draft was published several years
after OAuth 2.0), as well as how large corporations have decided to run
their ASs where they want to have (what feels like) more control over the
things talking to their servers.

On Fri, Feb 26, 2021 at 8:22 AM Warren Parad  wrote:

> A) I don't think it is helpful to talk about what other WGs are doing, or
> how GNAP attempts to fix or not fix these problems.
> B) Sharing statements like this:
>
>> Right, it’s possible to patch OAuth to do this, but the whole
>> “registration equals trust” mindset is baked into OAuth at a really core
>> level. That’s one of the main reasons there’s been hesitance at deploying
>> dynamic registration
>
> Don't help everyone come to the same conclusion, Who is "we" here, it begs
> the question "is there a mindset baked into OAuth", I think to work
> effectively we need to be talking about how to best to tackle challenges
> everyone and anyone brings up and not fallback on arbitrary statements. It
> would be one thing to point to a document which outlines the exact issues
> with dynamic registration and then we could potentially have a valuable
> conversation about "are those reasons still relevant or do we need to
> revisit."
>
> Right now it seems there is "Someone in the past decided this was a bad
> idea, so we can't do it", rather than actually having the conversation
> about it.
>
> Just based on the conversation, it seems like the obvious right thing to
> do is provide dynamic registration in OAuth. Will client developers do the
> wrong thing, sure. Might it be challenging to support in a simple way,
> maybe. But having the addition to OAuth to solve the problem is better than
> nothing, and further it starts to change the mindset that dynamic
> registration is and should be provided when appropriate.
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress .
>
>
> On Fri, Feb 26, 2021 at 5:11 PM Justin Richer  wrote:
>
>> Right, it’s possible to patch OAuth to do this, but the whole
>> “registration equals trust” mindset is baked into OAuth at a really core
>> level. That’s one of the main reasons there’s been hesitance at deploying
>> dynamic registration. It’s an extension that changes your trust model’s
>> assumptions, and does so in a way that is challenging for a lot of large
>> scale providers.
>>
>> That’s why I personally think it’s really important that we get away from
>> that registration model in GNAP, so we don’t repeat that same problem in
>> the same way. Some people will still deploy GNAP with static registration,
>> but this model becomes more exceptional than baseline. The philosophy of
>> what’s considered an extension vs. default is important.
>>
>>  — Justin
>>
>> On Feb 25, 2021, at 3:41 AM, Seán Kelleher  wrote:
>>
>> Yep, this is the big point - OAuth is designed to require the the third
>>> leg of trust that creates the NxM problem.
>>
>>
>> I believe the snippet of Justin's that you quoted actually shows you how
>> you can forgo the trust element using dynamic client registration. It still
>> allows a "server" to identify requests and impose security policies via the
>> client ID, but without requiring the client author to manually register the
>> client in advance of using it (e.g. in the case where the client author
>> doesn't even know what servers the client is going to be connecting to).
>> You still need the client ID, but anyone can get one whenever they need it.
>>
>> I'm also feeling a bit of confusion arising from a conflation of terms
>> between the regular client/server model and the terminology used in OAuth.
>> To be clear, in OAuth, the level of trust between the client and authZ
>> server only really depends on policy; as mentioned, dynamic client
>> registration can be used if you don't need any trust between the client and
>> AS.
>>
>> On Thu, 25 Feb 2021 at 08:22, Seán Kelleher  wrote:
>>
>>> Just to clarify, I assume in this discourse that the "server" in this
>>> client and server relationship refers to an AS/RS pair in OAuth
>>> terminology? Based on this, one big sticking point for me on the
>>> applicability of NxM, or even 1xM, is that all of the "M" RSs need to
>>> publish the same interface for any meaningful implementation in the first
>>> place.
>>>
>>> It probably makes more sense with email clients, since as Bron said,
>>> there is the common standard of POP. If we assume that all the email
>>> services that we want to connect to publish the same POP interface, and
>>> would accept tokens in the same way, then the way the authZ is handled is
>>> indeed the point 

Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

[Aaron Parecki]

> Sure, you could write it off as "a business problem" but

I did not mean to suggest that I was *writing it off* as a business
problem.

It *is* a very real problem, and I would very much like to see a solution,
however based on my experience it is not something that technology will
solve. This is demonstrated by the fact that there are all the pieces in
place already yet many organizations refuse to adopt them, and it’s
definitely not for a lack of understanding.

Aaron



On Wed, Feb 24, 2021 at 7:01 AM Jim Willeke  wrote:

> But in reality, Just "because the technology" is there there leaves out
> the practicality of creating a secure implementation. Sure, you could write
> it off as "a business problem" but many of the developers are small and not
> unusually single person operations that do not have the resources to create
> a specific team, or even a specific person, to work through all the
> specifications that are involved.
>
> I do believe, in general, specific implementations should not be within
> the specifications but a "Best Practices" or "Common Implementations"
> document to coincide with the specifications might be in order.
>
> Just spend some time on https://stackexchange.com/filters/4229/oauth and
> you will see the issue and struggles.
>
>
> --
> -jim
>
> Jim Willeke
>
>
> On Wed, Feb 24, 2021 at 8:46 AM Aaron Parecki  wrote:
>
>> > You type your email address into {The Bat} to begin configuration.
>> {The Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My
>> ISP}. The discovery document reveals that {My ISP} supports open dynamic
>> client registration [3][4] so {The Bat} registers and gets issued with a
>> client id and client secret. {The Bat} then does a normal OAuth flow to get
>> an access token to access your emails from {My ISP}. If you later stop
>> using {The Bat} you can go to your page on {My ISP} and revoke its access
>> because it has a unique client id.
>>
>> Like Neil says, the building blocks are all already there. The fact that
>> companies choose not to use them is not because the technology isn't there,
>> it's because it's a business problem.
>>
>> I'd be thrilled if the NxM problem were solved in practice, but
>> unfortunately that doesn't seem to be what's happened in the market. The
>> technical solution has been there a long time, so there's something else
>> going on.
>>
>> When I've brought up this topic in the past, most of the responses I've
>> gotten from the "big players" are along the lines of "lol we're not going
>> to let someone's software talk to us unless we have a legal arrangement
>> with the developer". The fact that dynamic client registration is barely
>> used is more because these service operators want the software developers
>> to agree to their terms of service before being able to access APIs.
>>
>> This is all to say that I agree it'd be nice to solve this problem, but
>> in the end, the IETF can't tell companies what to do with their products
>> and services.
>>
>> Aaron
>>
>>
>>
>>
>> On Wed, Feb 24, 2021 at 4:21 AM Neil Madden 
>> wrote:
>>
>>> On 24 Feb 2021, at 11:39, Bron Gondwana  wrote:
>>>
>>>
>>>
>>> […]
>>>
>>>
>>> Let's get down to use cases then, rather than talking in abstracts.
>>>
>>> I'm an end user with a copy of {The Bat email client} and I want to
>>> connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widely
>>> popular open standard.  I want to be able to authenticate to each of those
>>> services without saving my plaintext passwords on my hard disk where the
>>> next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and
>>> all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account,
>>> leaving me destitute.
>>>
>>> But, {The Bat} doesn't have a trusted client cert from my isp, because
>>> who does - so there's no good protocol for me - it's either plaintext auth,
>>> or it's some architecture astronaut multi-party nonsense that's massively
>>> over specified and doesn't work half the time.  So I write a plain text
>>> password on a post-it note which is lying in the dust under my monitor
>>> because the glue has gone bad, and I hope I never accidentally click
>>> "remember me" when I type it in.
>>>
>>> That's been the reality of the end user experience for very many years.
>>>
>>> NxM means that you can authenticate an arbitrary client aga

Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

[Aaron Parecki]

> You type your email address into {The Bat} to begin configuration. {The
Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}.
The discovery document reveals that {My ISP} supports open dynamic client
registration [3][4] so {The Bat} registers and gets issued with a client id
and client secret. {The Bat} then does a normal OAuth flow to get an access
token to access your emails from {My ISP}. If you later stop using {The
Bat} you can go to your page on {My ISP} and revoke its access because it
has a unique client id.

Like Neil says, the building blocks are all already there. The fact that
companies choose not to use them is not because the technology isn't there,
it's because it's a business problem.

I'd be thrilled if the NxM problem were solved in practice, but
unfortunately that doesn't seem to be what's happened in the market. The
technical solution has been there a long time, so there's something else
going on.

When I've brought up this topic in the past, most of the responses I've
gotten from the "big players" are along the lines of "lol we're not going
to let someone's software talk to us unless we have a legal arrangement
with the developer". The fact that dynamic client registration is barely
used is more because these service operators want the software developers
to agree to their terms of service before being able to access APIs.

This is all to say that I agree it'd be nice to solve this problem, but in
the end, the IETF can't tell companies what to do with their products and
services.

Aaron




On Wed, Feb 24, 2021 at 4:21 AM Neil Madden 
wrote:

> On 24 Feb 2021, at 11:39, Bron Gondwana  wrote:
>
>
>
> […]
>
>
> Let's get down to use cases then, rather than talking in abstracts.
>
> I'm an end user with a copy of {The Bat email client} and I want to
> connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widely
> popular open standard.  I want to be able to authenticate to each of those
> services without saving my plaintext passwords on my hard disk where the
> next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and
> all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account,
> leaving me destitute.
>
> But, {The Bat} doesn't have a trusted client cert from my isp, because who
> does - so there's no good protocol for me - it's either plaintext auth, or
> it's some architecture astronaut multi-party nonsense that's massively over
> specified and doesn't work half the time.  So I write a plain text password
> on a post-it note which is lying in the dust under my monitor because the
> glue has gone bad, and I hope I never accidentally click "remember me" when
> I type it in.
>
> That's been the reality of the end user experience for very many years.
>
> NxM means that you can authenticate an arbitrary client against an
> arbitrary server so long as they are both speaking a known public protocol,
> without needing to build a trust relationship between the client vendor and
> the server vendor first.
>
>
> Does the following meet your needs?
>
> You type your email address into {The Bat} to begin configuration. {The
> Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}.
> The discovery document reveals that {My ISP} supports open dynamic client
> registration [3][4] so {The Bat} registers and gets issued with a client id
> and client secret. {The Bat} then does a normal OAuth flow to get an access
> token to access your emails from {My ISP}. If you later stop using {The
> Bat} you can go to your page on {My ISP} and revoke its access because it
> has a unique client id.
>
> [1]: https://openid.net/specs/openid-connect-discovery-1_0.html
> [2]: https://tools.ietf.org/html/rfc8414
> [3]: https://openid.net/specs/openid-connect-registration-1_0.html
> [4]: https://tools.ietf.org/html/rfc7591
>
>
> Any "trust relationship" is made through a user both who trusts the client
> and trusts the server, and it's not transitive over to other users of the
> same client and the same server.  The client author doesn't need to get a
> signed "I trust you" from every single server, and the server author
> doesn't have to go identify every single client.
>
> That's what NxM means to a user, the ability to use arbitrary clients with
> arbitrary servers so long as they both implement a documented protocol.
> Interoperability.
>
>
> That’s fine for your use-case, but that isn’t everybody’s use-case. Other
> use-cases (such as Open Banking) involve regulatory or policy frameworks in
> which open dynamic client registration is not appropriate. JMAP could have
> an RFC describing the use of OAuth with JMAP that mandates open dynamic
> client registration and discovery.
&g

Re: [OAUTH-WG] Providing feedback to OAuth2.1

[Aaron Parecki]

Hi Roberto,

The authors are keeping track of open discussions on this GitHub repo
https://github.com/aaronpk/oauth-v2-1

If you'd like to provide feedback on the record, then this email list is
the best place for that. You're also welcome to open issues on the GitHub
repo, but that is an unofficial forum and will be seen by basically just
the authors.

---
Aaron Parecki
https://aaronparecki.com


On Wed, Oct 28, 2020 at 9:51 AM Roberto Polli  wrote:

> Hi everybody,
>
> I'd like to provide some feedback to draft-ietf-oauth-v2-1. Is there a repo
> (eg. like https://github.com/httpwg/http-core) where I can see the open
> issues,
> catch up with the discussion and discuss PRs?
>
> Thanks for your hard work and have a nice day,
> R:
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] BCP: Client collaborative attacks

[Aaron Parecki]

Thank you Seán, this is an excellent analysis and makes this attack much
easier to understand. I completely agree with your rewritten text, both
that it better describes the situation as well as the conclusion that it
ends up being a bit too general for the BCP.

---
Aaron Parecki
https://aaronparecki.com
https://oauth2simplified.com

On Mon, Oct 26, 2020 at 2:19 PM Seán Kelleher  wrote:

> I hadn't come across this idea before, it's an interesting angle and for
> me it's a nice new example to help highlight the difference between authZ
> and authN. It reminds me of sharing access cards to get into computer labs
> in college. Some thoughts:
>
>- It took me a while to figure out the agent, victim, intent and
>impact for the attack based on its name and description. The presented term
>may already be accepted, but if not, would you consider the term
>"authorization sharing attack"? I feel that this conveys the intent and
>impact of the attack a bit more clearly.
>
> However, if the access token contains claims that allow the RS to uniquely
>> identify the legitimate holder of the access token
>> and if the RS only accepts access tokens that are able to uniquely
>> identify the legitimate holder of the access token, then
>> this attack can be mitigated since the client collaborative attack
>> becomes an impersonation attack.
>
>
>- Being pedantic, I don't think this mitigates the attack so much as
>it reduces it to the mentioned impersonation attack. However, I'm not sure
>that "impersonation attack" is the right term to use here, as this scenario
>seems to imply that the subject consents to the impersonation, which is in
>contrast to the standard impersonation attack where the subject is the
>victim.
>
> For mitigating the collaborative attack, either a "sub" claim must be
>> present or any combination of other claims allowing for the RS
>> to uniquely identify the holder of the access token must be present
>> inside an access token
>>
>
>- A more general phrasing of this could be that "it should be possible
>to use an access token to uniquely identify an individual". I say this
>because this kind of identification can also be done using opaque tokens,
>in which case the claims are not necessarily "inside" the access token.
>
> Under these conditions, it should be observed that the first user might be
>> unlikely to be willing to collaborate since the other user would be able
>> to perform actions on behalf of the first user and the first user would
>> be held responsible of the actions of the second user.
>
>
>- This seems to be the main justification as to why the above
>mitigations are considered as such. I don't agree with the conclusion
>because I feel it's based on debateable assumptions, the main one being
>that the "first user might be unlikely to be willing to collaborate" if
>they know that their access token identifies them, which tries to predict
>human behaviour. It also depends on the user knowing whether access tokens
>can be used to identify them.
>- I'm again being pedantic, but I would also note that just being able
>to identify a user from an access token is unlikely to be a sufficient
>deterrent, it would need to be coupled with logging of all access token
>usages for auditing purposes. Again though, this assumes that we can
>predict human behaviour.
>- Following on from one of my above points, I would remove the user
>element from this section, and avoid calling it a mitigation. I'd instead
>outline that if access tokens can be used to identify individuals then it
>reduces possible authZ sharing attacks to authN sharing attacks.
>
> I think this is an interesting attack vector, particularly because it
> requires the authZ sharer to have internal knowledge of how the RS
> operates, and so has relatively niche applications. It also seems to assume
> that the RS in question doesn't store user IDs with access logs, at which
> point, is it simpler to just recommend that authN'd requests to an RS
> should be logged with user IDs?
>
> I've written up an alternative for consideration:
>
> Authorization sharing attack
>>
>> If access tokens are not used to identify individuals, and if this
>> information is known to an individual, then such an individual may use
>> knowledge of this to share the authorization granted to them by access
>> tokens. This may be done by sharing access tokens across clients and
>> individuals, at which point the RS will not be able to distinguish between
>> different subjects and clients using the sam

Re: [OAUTH-WG] New draft: Mix-up prevention - adding "iss" parameter to the authorization response

[Aaron Parecki]

To capture my comment from the interim meeting call, I would like to see
some explicit text in this draft (as well as the Security BCP section that
will reference this draft) that clarifies this parameter is not needed and
this attack is not relevant if a client only interacts with one
authorization server.

More broadly, I would like to make sure the scope of the attacks that this
prevents is clarified so that people may better understand when they do not
need to worry about this and don't need to use this new parameter.

---
Aaron Parecki
https://aaronparecki.com


On Mon, Oct 26, 2020 at 7:33 AM Karsten Meyer zu Selhausen <
karsten.meyerzuselhau...@hackmanit.de> wrote:

> Hello WG,
>
> adding the issuer identifier to the authorization response as a
> countermeasure to mix-up attacks is well-known on this list and already
> part of the security BCP (see 4.4.2
> <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-4.4.2>
> ).
> However, the "iss" parameter is currently not properly specified. Daniel
> and I wrote an ID to solve this issue.
>
> We would like to ask the working group to give us feedback on our first
> draft version:
> https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-00
>
> Abstract
>
>This document specifies a new parameter "iss" that is used to
>explicitly include the issuer identifier of the authorization server
>in the authorization response of an OAuth authorization grant.  If
>implemented correctly, the "iss" parameter serves as an effective
>countermeasure to "mix-up" attacks.
>
>
> The need for a proper specification of the "iss" parameter was discussed
> in this thread:
> https://mailarchive.ietf.org/arch/msg/oauth/DQR2ZXtGKfa-8UGtuPYyZoAaBIc/
>
> Best regards,
> Karsten
>
>
> --
> Karsten Meyer zu Selhausen
> IT Security Consultant
> Phone:+49 (0)234 / 54456499
> Web:  https://hackmanit.de | IT Security Consulting, Penetration Testing, 
> Security Training
>
> Does your OAuth or OpenID Connect implementation use PKCE to strengthen the 
> security? Learn more about the procetion PKCE provides and its limitations in 
> our new blog 
> post:https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client
>
> Hackmanit GmbH
> Universitätsstraße 60 (Exzenterhaus)
> 44789 Bochum
>
> Registergericht: Amtsgericht Bochum, HRB 14896
> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. 
> Christian Mainka, Dr. Marcus Niemietz
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Implementation questions around refresh token rotation

[Aaron Parecki]

Hi all, I have a couple questions for those of you who have implemented
refresh token rotation...

Have you included the option of a grace period on refresh token use,
allowing multiple uses within some time window? I'm wondering because a
grace period where a refresh token may be used more than once would work
around the problem that has been brought up, of a mobile app accidentally
using a refresh token more than once during normal operation because
different threads are unable to coordinate between themselves. However that
also kind of defeats the purpose since attacks within that grace period
would be hard to detect. I'm looking for an idea of where people have
landed on that issue in practice.

If you have implemented a grace period, then how do you handle expiring the
additional refresh tokens that have been granted? For example, if RT "R1"
is used twice, resulting in new ATs "A1.1", "A1.2" and new RTs "R1.1" and
"R1.2", what happens if "R1.2" is then later used? Would you invalidate
"R1.1" at that point? If so, why, and if not, why not?

It would be most interesting to hear practical experience from people who
have already built refresh token rotation into a system.

Thanks!

---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JSON based access token requests for OAuth 2.1

[Aaron Parecki]

The spec does clearly require form-encoded POST requests to the token
endpoint, it's not just an implication. The requests made include simple
key/value pairs so there's nothing really gained by making this a JSON
post. Changing that at this point would be a drastic breaking change to
pretty much all existing code for very little benefit if any.

That said, Justin Richer did already write up a draft exploring this topic,
but it hasn't shown much interest in the group yet.

https://www.ietf.org/id/draft-richer-oauth-json-request-00.html

Aaron






On Tue, Oct 6, 2020 at 7:18 AM Janak Amarasena 
wrote:

> Hi All,
>
> As per my understanding OAuth 2(RFC6749) doesn't mandate any specific
> media type to be used in the access token request. The spec implies
> application/x-www-form-urlencoded should be used. Since the media type
> application/json is very popular and widely used now, any thoughts on
> referencing the use of this as well for access token requests?
>
> Best Regards,
> Janak Amarasena
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-07.txt

[Aaron Parecki]

Hi all,

Based on some of the discussions from our virtual interim meeting and the
OAuth Security Workshop, I published a (minor) update to the browser app
BCP.

https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07

The primary changes are:

* Revised the language around PKCE/Implicit to clarify that PKCE applies
only when issuing access tokens
* Clarified that ASs MUST NOT issue access tokens in the authorization
response
* Changed "MUST" to "SHOULD" for rotating refresh tokens
* Editorial clarifications to the summary bullet point section

I believe these changes reflect all the latest discussions we've had. There
are still some outstanding items I am aware of that need adding to the
document as well. Apologies for the delay in getting this out. I hope we
can pick up the momentum on this document again!

Aaron Parecki



On Fri, Oct 2, 2020 at 4:36 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
> Title   : OAuth 2.0 for Browser-Based Apps
> Authors : Aaron Parecki
>   David Waite
> Filename: draft-ietf-oauth-browser-based-apps-07.txt
> Pages   : 21
> Date: 2020-10-02
>
> Abstract:
>This specification details the security considerations and best
>practices that must be taken into account when developing browser-
>based applications that use OAuth 2.0.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07
>
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-browser-based-apps-07
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] third party applications

[Aaron Parecki]

I agree. While the original motivations for OAuth were to support
third-party apps, it's proven to be useful in many other kinds of
situations as well, even when it's a "first-party" app but the OAuth server
is operated by a different organization than the APIs. I don't think the
abstract needs any qualification on this and would only confuse people
further. Any clarifications of which situations are appropriate for using
OAuth could be explored in a different section in the spec.

Aaron Parecki

On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt  wrote:

> I agree. OAuth works for 3rd as well as 1st parties as well.
>
> > On 28. Aug 2020, at 05:26, Dima Postnikov  wrote:
> >
> > Hi,
> >
> > Can "third-party" term be removed from the specification?
> >
> > The standard and associated best practices apply to other applications
> that act on behalf of a resource owner, too (internal, "first-party" and
> etc).
> >
> > Regards,
> >
> > Dima
> >
> > The OAuth 2.1 authorization framework enables a third-party
> >
> >application to obtain limited access to an HTTP service, either on
> >behalf of a resource owner by orchestrating an approval interaction
> >between the resource owner and the HTTP service, or by allowing the
> >third-party application to obtain access on its own behalf.  This
> >specification replaces and obsoletes the OAuth 2.0 Authorization
> >Framework described in
> > RFC 6749.
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Privacy Considerations section in OAuth 2.1?

[Aaron Parecki]

I agree that there is nothing unique to PAR that would justify adding the
privacy considerations mentioned to that draft. I wouldn't oppose adding a
privacy considerations section to OAuth 2.1 though.

Aaron


On Mon, Aug 10, 2020 at 9:42 AM Dick Hardt  wrote:

> In the PAR meeting today, Denis requested there be a privacy
> considerations section in PAR. I don't think there is anything specific in
> PAR that would change the privacy considerations of OAuth, and am checking
> if there is WG interest, and consensus, on including a Privacy
> Considerations section in the OAuth 2.1 draft.
>
> /Dick
> ᐧ
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

[Aaron Parecki]

I have a draft from a coworker that defines a cookie response mode and
cookie bearer token usage. It's something we've considered bringing to the
working group but haven't actually proposed yet. Is this the kind of thing
you're talking about?

https://github.com/jaredhanson/draft-oauth-cookie-response-mode/blob/master/spec.txt

This looks like a good starting point and I am happy to work with Jared on
refining this.

---
Aaron Parecki
https://aaronparecki.com
https://oauth2simplified.com

On Thu, Jul 30, 2020 at 1:55 PM Dick Hardt  wrote:

> I hear you Jim, but it is not so much rules, as expectations and
> expediency.
>
> There may be significant debate on how to do the feature. You would not
> want to hold up the OAuth 2.1 document for that would you? There are other
> documents already in flight -- which other ones should OAuth 2.1 wait for?
>
> Reducing the "20 standards" to one document was the goal of OAuth 2.1.
>
> Having said that, if members of the working group want to get working on
> this feature, and if it is completed quickly, it could be referenced or
> included in OAuth 2.1 depending on the relative timing.
>
> /Dick
>
>
>
>
> ᐧ
>
> On Thu, Jul 30, 2020 at 1:47 PM Jim Manico  wrote:
>
>> I politely encourage the rules to be bent and to integrate this basic but
>> fundamental security control into the core standard.
>>
>> This is just basic security; we want as much basic security in the core
>> of any standard. Dev’s now need to read 20 standards to get OAuth2
>> basics... and that’s a barrier to entry.
>>
>> --
>> Jim Manico
>> @Manicode
>>
>> On Jul 30, 2020, at 3:21 PM, Dick Hardt  wrote:
>>
>> 
>> One of the constraints of the OAuth 2.1 document that aligned the WG was
>> it would have no new features.
>>
>> I'd recommend a separate document for the cookie bearer token feature.
>>
>> ᐧ
>>
>> On Thu, Jul 30, 2020 at 12:15 PM Jim Manico  wrote:
>>
>>> Yea to cookie configuration suggestions!
>>>
>>> I suggest SameSite=LAX at least, which is actually the default behavior
>>> in chrome if you do not set the samesite value. LAX will not break links
>>> that originate from emails, STRICT will.
>>>
>>> Point being is that CSRF defense is easy. XSS defense is brutally hard
>>> in apps with complex UI’s!
>>>
>>> --
>>> Jim Manico
>>> @Manicode
>>>
>>>
>>> On Jul 30, 2020, at 1:13 PM, Warren Parad  wrote:
>>>
>>> 
>>>
>>>> Cookie storage of tokens does leave one open to CSRF attacks so it's
>>>> certainly a trade-off. But CSRF is much easier to defense against that XSS
>>>> and cookies are a better choice if the specific risk of having tokens
>>>> stolen via XSS matters to your threat model.
>>>
>>>
>>> I would assume if we included cookie language, it would explicitly
>>> specify *Secure; HttpOnly; SameSite=Strict* as the recommendation, and
>>> then neither XSS nor CSRF should be a problem (right?)
>>>
>>>
>>> OAuth 2.1 isn't supposed to add new features that don't already exist,
>>>> but this sounds like a good candidate to develop as an OAuth extension..
>>>
>>>
>>> Is this really a *new feature* though?
>>>
>>> Okay, I'll submit that RFC 6749 does state the cookie wouldn't be
>>> created by the AS.
>>>
>>>> 5.1.  Successful Response
>>>> <https://tools.ietf.org/html/rfc6749#section-5.1>
>>>> <https://tools.ietf.org/html/rfc6749#section-5.1>   The authorization
>>>> server issues an access token and optional refresh
>>>> <https://tools.ietf.org/html/rfc6749#section-5.1>   token, and
>>>> constructs the response by
>>>> *adding the following parameters*
>>>> <https://tools.ietf.org/html/rfc6749#section-5.1>*   to the
>>>> entity-body of the HTTP response* with a 200 (OK) status code:
>>>> <https://tools.ietf.org/html/rfc6749#section-5.1>
>>>
>>>
>>> However that wouldn't prevent a client using the password grant (I know
>>> I said a bad word) or authorization code flow from creating the cookie to
>>> contain that. Specifically
>>>
>>>> 7.  Accessing Protected Resources
>>>>The client accesses protected resources by presenting the access
>>>>token to the resource server.  The resource server MUST validate the
>>>>access token and ensure that it has not expired and that its

Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

[Aaron Parecki]

I haven't seen any OAuth drafts that talk about sending OAuth access tokens
in HTTP cookies. OAuth 2.1 isn't supposed to add new features that don't
already exist, but this sounds like a good candidate to develop as an OAuth
extension.

---
Aaron Parecki
https://aaronparecki.com
https://oauth2simplified.com

On Thu, Jul 30, 2020 at 9:35 AM Jim Manico  wrote:

> In a browser, HTTPOnly cookies are the *only* location where an access
> (or other) token can be stored in a way where it *cannot be stolen from
> XSS*.
>
> It's a very strong place to store tokens from a security point of view.
>
> Cookie storage of tokens does leave one open to CSRF attacks so it's
> certainly a trade-off. But CSRF is much easier to defense against that XSS
> and cookies are a better choice if the specific risk of having tokens
> stolen via XSS matters to your threat model.
>
> - Jim
> On 7/30/20 11:43 AM, Warren Parad wrote:
>
> https://www.ietf.org/id/draft-ietf-oauth-v2-1-00.html#name-bearer-tokens
>
> It seems recently more and more common to pass the access_token to some RS
> via a cookie, yet 7.2.1 says it defines two methods. I think we need some
> RFC2119 <https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html#RFC2119> 
> keywords
> here, to suggest that either SHOULD use one of these two, or MUST. And then
> optionally state whether or not we recommend or reject the use of cookies
> as a place for access tokens. It's also possible that the language threw me
> off, because would an access token in a cookie be a bearer token, but no
> matter, if I'm having this thought, then surely others have it as well,
> right?
>
> [image: image.png]
>
> Warren Parad
>
> Founder, CTO
> Secure your user data and complete your authorization architecture.
> Implement Authress <https://bit.ly/37SSO1p>.
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Authorization Code Grant diagram Improvement OAuth 2.1 draft-ietf-oauth-v2-1

[Aaron Parecki]

These numbers in the diagram correspond to the numbered steps in the
paragraphs below the diagram. Perhaps using non-duplicated numbers would
help, such as "1a" and "1b" instead of two instances of "1"? Although I'm
not sure how that would work exactly because the "1/2/3" are really just a
single action as described by the "Note" below the diagram in your
screenshot.

---
Aaron Parecki
https://aaronparecki.com
https://oauth2simplified.com

On Thu, Jul 30, 2020 at 8:43 AM Warren Parad  wrote:

>
> https://www.ietf.org/id/draft-ietf-oauth-v2-1-00.html#name-authorization-code-grant
>
> Can we avoid using (1, 2, 3) on the left side of the diagram to describe,
> I'm not even sure what they are supposed to represent, not to mention the
> RO in the diagram doesn't really provide value (for me) relevant to the
> code grant flow. It's confusing to see these numerical identifiers twice in
> the same picture. But maybe there is something hidden in this that I'm
> missing, still 3a and 3b could be used to identify different legs of the
> same code path.
> [image: image.png]
>
>
> *Warren Parad*
> Secure your user data and complete your authorization architecture.
> Implement Authress <https://bit..ly/37SSO1p>.
> <https://rhosys.ch>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

[Aaron Parecki]

I know this is a bit of an old thread to dig up, but as I'm working through
this draft again, something is sticking out to me about this.

In every other instance of "*_uri" in OAuth and extensions, the value is a
URI (usually https) which will be visited by the user's browser or be sent
a POST request from a client. In the case of PAR, this "request_uri" is
actually just an identifier that is *added* to an existing URL, the
authorization endpoint, not a URL that will be visited itself. This
discrepancy is bothering me.

I would have expected that either:

* The PAR response includes a "request_uri" which is the full URL that the
client would redirect the user's browser to, OR
* The PAR response includes a "request_id" which it adds in the query
string to the authorization endpoint and then redirects the browser to

For example:

POST /as/par HTTP/1.1

response:
{
  "request_uri": "
https://as.example.com/auth?request=bwc4JK-ESC0w8acc191e-Y1LTC2;,
  "expires_in": 60
}

then the user's browser is sent to whatever the value of "request_uri" is

OR

POST /as/par HTTP/1.1

response:
{
  "request_id":
"urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LTC2",
  "expires_in": 60
}

then the "request_id" is added to the authorization endpoint (as currently
described by PAR)

https://as.example.com/auth?
client_id=s6BhdRkqt3_uri=urn%3Aietf%3Aparams
%3Aoauth%3Arequest_uri%3Abwc4JK-ESC0w8acc191e-Y1LTC2

My personal preference is the first option, keeping the term "request_uri"
but having it actually be the full URI, to simplify the job of the client.
In that model, the client doesn't have to mess with building URLs, and
actually provides additional flexibility for the AS as well since that
endpoint no longer needs to be the exact same URL as the authorization
endpoint.

---
Aaron Parecki
https://aaronparecki.com


On Thu, Jan 16, 2020 at 8:25 AM Torsten Lodderstedt  wrote:

> I just thought about another option. What if we change PAR to not use the
> request_uri parameter but a new parameter, e.g. request_id?
>
> That would decouple both specs. The reason why we use request_uri was to
> make the life of clients easier since they can use the standard library
> function for request objects to pass the PAR reference to the AS. Is this
> worth the trouble?
>
> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>
> +1 to this approach, and it sounds like JAR might need to come back to go
> through another round anyway thanks to the breaking changes the IESG pushed
> into it after it left WGLC.
>
> I’d rather see us get this right than publish something many of us think
> is broken.
>
> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>
>  — Justin
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - OAuth 2.1 document

[Aaron Parecki]

Just to clarify, this thread is a call for adoption, not meant to discuss
the details of this particular draft.

Any issues with the draft can be raised as new threads. But right now, the
question posed to the list is whether the group thinks this document should
be adopted as a working group item.

Oh, and +1 from me :-)

Aaron Parecki
https://aaronparecki.com

On Wed, Jul 15, 2020 at 11:57 AM Warren Parad  wrote:

> I only recently joined this WG DL, so maybe this was already discussed by
> I have two things I'm confused/curious about:
>
> 1. Can we avoid using (1, 2, 3) on the left side of the diagram to
> describe, I'm not even sure what they are supposed to represent, not to
> mention the RO in the diagram doesn't really provide value (for me)
> relevant to the code grant flow. It's confusing to see these numerical
> identifiers twice in the same picture. But maybe there is something hidden
> in this that I'm missing, still 3a and 3b could be used to identify
> different legs of the same code path.
> [image: image.png]
>
> 2. It seems recently more and more common to pass the access_token to some
> RS via a cookie, yet 7.2.1 says it defines two methods. I think we need
> some RFC2119
> <https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html#RFC2119> keywords
> here, to suggest that either SHOULD use one of these two, or MUST. And then
> optionally state whether or not we recommend or reject the use of cookies
> as a place for access tokens. It's also possible that the language threw me
> off, because would an access token in a cookie be a bearer token, but no
> matter, if I'm having this thought, then surely others have it as well,
> right?
>
> [image: image.png]
>
>
> *Warren Parad*
> Secure your user data and complete your authorization architecture.
> Implement Authress <https://bit.ly/37SSO1p>.
> <https://rhosys.ch>
>
>
> On Wed, Jul 15, 2020 at 7:55 PM Dick Hardt  wrote:
>
>> +1
>>
>> On Wed, Jul 15, 2020 at 10:42 AM Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com> wrote:
>>
>>> All,
>>>
>>> This is a *call for adoption* for the following *OAuth 2.1* document as
>>> a WG document:
>>> https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html
>>>
>>> Please, provide your feedback on the mailing list by *July 29th.*
>>>
>>> Regards,
>>>  Rifaat & Hannes
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request))

[Aaron Parecki]

> the AS will have the knowledge of these request parameters such as
"please let me make a payment with the amount of 45 Euros"
or "please give me read access to folder A and write access to file X"

Typically in OAuth it's the authorization server's job to inform users and
protect access to their resources. Obviously in order to do that the AS
must know about the details of the request.

Can you please clarify the scenario in which you would want the AS to have
no information about the request that it's authorizing?

Aaron Parecki




On Wed, May 27, 2020 at 10:20 AM Denis  wrote:

> As indicated in the abstract:
>
> "This document introduces the ability to send request parameters in a JSON
> Web Token (JWT) instead,
>   which allows the request to be signed with JSON Web Signature (JWS)".
>
> This approach has a major consequence which is not indicated in the
> "Privacy Considerations section:
> the AS will have the knowledge of these request parameters such as "please
> let me make a payment with the amount of 45 Euros"
> or "please give me read access to folder A and write access to file X".
>
> Such an approach has privacy issues which are currently not documented in
> the Privacy Considerations section.
>
> The AS would be in a position to know, not only which resources servers
> are going to be accessed, but also what kind of operations
> are going to be performed by its clients on the resource servers. With
> such an approach, ASs will have a deep knowledge of every
> operation that can be performed by a user on every RS.
>
> As a consequence, the AS would also be in a position to trace the actions
> performed by its users on the resources servers.
>
> Other approaches that are more "privacy friendly" should be considered to
> address the initial problem.
>
> Denis
>
> PS. This email closely relates to the previous email sent on the WG
> mailing list with the following topic:
>Comments on OAuth 2.0 Rich Authorization Requests
> (draft-ietf-oauth-rar-01)
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

[Aaron Parecki]

So if I'm understanding this correctly, it sounds like the AS needs to
reject a token request with code_verifier if the authorization code was
issued in response to a request that did not contain a code_challenge. This
to me sounds like it would be simpler to just say the code_challenge and
code_verifier are always required.

That said, I do understand the previously discussed concerns around
existing OpenID Connect clients.

I believe the text that Daniel proposed is the best of both worlds, and I
support making this change in both OAuth 2.1 and the Security BCP.

Aaron Parecki



On Tue, May 19, 2020 at 9:29 AM Nov Matake  wrote:

> Yes.
>
> The root problem isn’t the mix-use of PKCE and nonce, it’s PKCE
> implementation bug.
> Yeah, all PKCE implementation MUST reject such requests, regardless it’s
> OAuth 2.1 or 2.0.
>
> (and it’s probably because of PKCE spec’s ambiguity..)
>
> 2020/05/20 1:13、Mike Jones のメール:
>
> So it sounds me like the fix is to have servers reject PKCE requests with
> incomplete parameter sets: requests that only contains one of
> code_challenge and code_verified.  Will that eliminate the attack, Nov?
>
>-- Mike
>
> *From:* OAuth  *On Behalf Of *Nov Matake
> *Sent:* Monday, May 18, 2020 11:50 PM
> *To:* Daniel Fett 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>
> Sure, feel free to add the senario to your post.
>
> FYI:
> my OAuth2 server ruby gem rejects such token requests,
>
> https://github.com/nov/rack-oauth2/blob/master/lib/rack/oauth2/server/extension/pkce.rb#L28
> and Google also does the same.
> https://gist.github.com/nov/9feba86685bd3b18b4bf7bfb88022046
>
> So I'm guessing such behavior is relatively rare-case, hopefully.
>
> iPadから送信
>
>
> 2020/05/19 15:43、Daniel Fett のメール:
>
> 
> Hi,
>
> Am 19.05.20 um 04:55 schrieb Nov Matake:
>
> I thought the server MUST reject such token requests, but I couldn’t find
> such definition in RFC7636...
>
> > The client will send the code, along with a (now not matching)
> code_verifier to the server. The server will ignore the code_verifier (as
> it was not expected) and send back an access token and ID token to the
> client.
>
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/#noncepkce-sidestep-attack
>
> If the behavior is acceptable by RFC7636, "Nonce/PKCE Sidestep Attack”
> would be possible.
>
> I *think* that there is nothing preventing servers from sometimes using
> PKCE and sometimes using Nonce. I assume that this is out of the scope of
> the existing specifications.
>
> I would be interested to hear how actual implementations handle this in
> practice.
>
>
> Plus, with such AS behavior, CSRF protection using PKCE can also be
> bypassed as below.
> 1. The attacker removes code_challenge from his/her own AuthZ
> Req, receives a non-code_challenge-bound code, and sends it to the victim..
> 2. The client receives the attacker’s code from the victim, and sends it
> to the AS w/ the valid code_verifier bound to the victim’s browser session.
> 3. The AS ignores the code_verifier and returns tokens.
>
> If that’s the case, current OAuth 2.0 PKCE implementation can be weaker
> than expected..
>
> Excellent point!
>
> Would it be okay if I add that attack to the original post (with credits,
> of course)?
>
> -Daniel
>
>
> nov
>
>
> 2020/05/19 1:54、Daniel Fett のメール:
>
> Hi all,
>
> Talking to Torsten, we realized that providing a generic extension point
> here is probably not a good idea. It is really hard to tell what protects
> you from code injection and what does not, and people might come up with
> all sorts of non-standard and potentially insecure solutions.
>
> Even just for PKCE vs. Nonce, it is not obvious if they provide the same
> level of protection. In an attempt to answer this question, I tried to come
> up with a more systematic analysis of "PKCE vs Nonce". I wrote up my
> results here:
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/
>
> Although this is not a formal analysis, I hope that I have covered all
> interesting cases. Please review the text and let me know if I have missed
> something or if there are any mistakes.
>
> The main results are:
>
>1. In terms of protection against CSRF and code misuse, PKCE and Nonce
>provide similar levels of security, with a slight advantage for PKCE.
>2. In practice, a circumvention of both mechanisms, however, is
>possible if an AS allows a client to choose between PKCE and Nonce and the
>client makes use of this freedom. I propose to call this attack the
&g