[OAUTH-WG] Browser-Based Applications - Document Shepherd Review

[Rifaat Shekh-Yusef <[e-mail]>]

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