Hi, As the shepherd for this document, I have reviewed the following version of the Browser-based App draft: https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-19.html
I have the following comments/questions: 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? 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”? 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? • “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? 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? Section 6.1.3.3.2 I might be missing something here: “For such requests, named "CORS-safelisted Requests", the browser will simply send the request and prevent access to the response if the server did not send the proper CORS headers.” The above statement indicates that for these requests, the browser ignores the response if it did not get a proper CORS from the server. “The consequence of this behavior is that certain endpoints of the resource server could become vulnerable to CSRF, even with CORS enabled as a defense. For example, if the resource server is an API that exposes an endpoint to a body-less POST request, there will be no preflight request and no CSRF defense.” This implies that just because there is no preflight request, that the server is vulnerable; would not the browser just ignore the response as indicated in the previous statement? 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? Section 6.2.2.1 “The endpoint that initializes the Authorization Code flow (step C) is …” “initializes” -> “initiates”? 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? 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? 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”? 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”? Section 6.3.4.2.3 “even when it is associated with a flow that was initialized by the attacker.” “initialized” -> “initiated”? 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? Regards, Rifaat
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
