Brian, as a co-author of the mentioned TMI-BFF draft, do you have an opinion on whether this draft should mention it inline as is currently in the doc, or whether we should remove the paragraph and mark the TMI-BFF draft as replaced by the Browser BCP?
Aaron On Thu, Dec 19, 2024 at 6:11 AM Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> wrote: > Thanks Aaron and Philippe! > > See a few replies below. > > Regards, > Rifaat > > > On Wed, Dec 18, 2024 at 4:08 PM Aaron Parecki <aaron= > 40parecki....@dmarc.ietf.org> wrote: > >> Hi all, the authors have published a new draft of the Browser-Based Apps >> BCP addressing Rifaat's comments from the shepherd writeup. Notes on the >> individual points are below, copied from Philippe's PR for these changes on >> GitHub. >> >> Section 6.1.1 >> “This response to the browser will also trigger the reloading of the >> JavaScript application (H).” >> I am assuming that there is a reason for this reload, but that is not >> clear to me. Can you elaborate on why a reload is needed? >> >> Clarified. >> >> Section 6.1.2.1 >> • There are few places where the word “initialize” is used, but I guess >> you meant to say “initiate”? >> • “Initialization URI” should that be “authorization URI”? >> >> Fixed. >> >> Section 6.1.2.2 >> • “These steps are not shown in the diagram, but would occur between step >> J and K. ” >> Should the BFF mint a new access token as soon as the existing access >> token has expired to allow for faster response to the request in step J? >> >> Reworded. >> >> • “Therefore, it is recommended to configure the lifetime of the >> cookie-based session managed by the BFF to be equal to the maximum lifetime >> of the refresh token. Additionally, when the BFF learns that a refresh >> token for an active session is no longer valid, it is recommended to >> invalidate the session.” >> “recommended” -> “RECOMMENDED”? >> Since this is a “recommended”, should there be some text to explain to >> the implementers when this recommendation might be ignored? >> >> Changed "recommended" to "makes sense" since this is not really a >> RECOMMENDATION, but mainly an observation for the implementer. All security >> hinges on the validity of the access/refresh token, and the session of the >> BFF is just to keep track of them. Keeping it around after a token expires >> is mainly ineffecient and pointless, but not really problematic. >> >> Section 6.1.3.2 >> “ >> • The BFF SHOULD enable the SameSite=Strict flag for its cookies >> • The BFF SHOULD set its cookie path to / >> • The BFF SHOULD NOT set the Domain attribute for cookies >> • The BFF SHOULD start the name of its cookies with the __Host- prefix >> ([CookiePrefixes]) >> ” >> The above statements use “SHOULD”, which implies that in some cases these >> can be ignored. Section 6.1.3.3.1 then elaborates on the “sameSite” flag. >> Should there be some text to elaborate on the others? >> >> I added a sentence to clarify this a bit. In my opinion, these can >> definitely all be MUSTs, but that may conflict with certain corner cases or >> implementation strategies. We can continue this discussion if the current >> fix is not sufficient. >> > I guess my question was: are there valid reasons for an implementer to > deviate from these security guidelines? > If the answer is no, then why not change all of them to MUST? > After all, the goal of this document is to encourage people to do the > right thing. > > > > >> Section 6.2.2.1 >> “The endpoint that initializes the Authorization Code flow (step C) is …” >> “initializes” -> “initiates”? >> >> Fixed. >> >> Section 6.2.2.2 >> “Therefore, it is recommended to configure the lifetime of the >> cookie-based session to be equal to the maximum lifetime of the refresh >> token if such information is known upfront. Additionally, when the >> token-mediating backend learns that a refresh token for an active session >> is no longer valid, it is recommended to invalidate the session.” >> “recommended” -> “RECOMMENDED”? >> Since this is a “recommended”, should there be some text to explain to >> the implementers when this recommendation might be ignored? >> >> Fixed like before. >> >> Section 6.3.2.2 >> • “using PKCE, and confirming that the authorization server supports PKCE” >> How would the browser-based app “confirm” that the authorization server >> supports PKCE? >> >> The developer would do that, but I've reworded this to avoid any >> confusion. >> >> Section 6.3.2.3 >> • “At this point, when the application attempts to use the refresh token >> after 8 hours, the request will fail and the application will have to >> re-initialize an Authorization Code flow that relies on the user's >> authentication or previously established session” >> “re-initialize” -> “re-initiate”? >> >> Fixed. >> >> Section 6.3.3.1 >> >> “For this reason, and those stated in Section 5.3.1 of [RFC6819], it is >> NOT RECOMMENDED for authorization servers to require client authentication >> of browser-based applications using a shared secret, as this serves no >> value beyond client identification which is already provided by the >> client_id parameter.” >> Since this is considered a bad practice, should we be more forceful here >> and try to change “NOT RECOMMENDED” to “MUST NOT”? >> >> Done. >> >> Section 6.3.4.2.3 >> “even when it is associated with a flow that was initialized by the >> attacker.” >> “initialized” -> “initiated”? >> >> Fixed. >> >> >> Section 7.2.4 >> “Performing OpenID Connect using the Authorization Code grant type >> provides the benefit of the client not needing to verify the JWT signature, >> …” >> With all kinds of middle boxes being used these days, should we encourage >> people to verify the JWT signature even if it was obtained over an HTTPS >> channel? >> >> Upon revisiting this section, this paragraph sticks out as somewhat >> problematic because it's not only a reference to OpenID Connect, but it's >> the only place where suggested behavior for OpenID Connect is recommended. >> We decided to just drop this paragraph entirely. (Issue 59 >> https://github.com/oauth-wg/oauth-browser-based-apps/issues/59) >> >> >> Section 6.2.1 >> “Note that an early draft ([tmi-bff]) already documented this concept, >> although the draft is is currently expired and has not been proposed for >> adoption to the OAuth Working Group.” >> Is this paragraph really needed? How would that help the implementer? >> >> >> I believe this came out of the discussions at IETF 114. After that >> meeting, we added the TMI-BFF pattern to the draft, and left this reference >> to a concrete proposal for implementing the pattern. While this draft was >> not developed further, it could be picked up again in the future, in which >> case leaving this reference here would give someone the breadcrumb trail to >> find. (Issue 58 >> https://github.com/oauth-wg/oauth-browser-based-apps/issues/58) >> >> >> > I just do not see the value for an implementer; in fact, it might be a > distraction. > If the goal is to allow others to find this draft, then we can add it to > the "Replaces" header of this document. > > > > >> Thanks, >> >> >> Aaron >> >> >> >> >> On Wed, Dec 18, 2024 at 1:00 PM <internet-dra...@ietf.org> wrote: >> >>> Internet-Draft draft-ietf-oauth-browser-based-apps-20.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 Applications >>> Authors: Aaron Parecki >>> David Waite >>> Philippe De Ryck >>> Name: draft-ietf-oauth-browser-based-apps-20.txt >>> Pages: 62 >>> Dates: 2024-12-18 >>> >>> 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-20.html >>> >>> A diff from the previous version is available at: >>> >>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-browser-based-apps-20 >>> >>> 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 mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
