Fragments, performance, and historic notes.

[will-bartlett]

In 7.2.1, "historic note", the current draft says:

Historically, the Implicit grant type provided an advantage to browser-based applications since JavaScript could always arbitrarily read and manipulate the fragment portion of the URL without triggering a page reload. This was necessary in order to remove the access token from the URL after it was obtained by the app.

[...] Modern browsers now have the Session History API [...] which provides a mechanism to modify the path and query string component of the URL without triggering a page reload.

The historic note is missing some context. Had RFC 6749 recommended query responses for browser-based apps, there would have been the additional page load AND an additional app download. Additionally, the document as a whole makes no mention of response_type=fragment.

Consider the following sequence of requests ("the authorization code flow"):

1. User navigates to https://contoso.com/
2. Contoso redirects the user to the OAuth provider https://oauth.example/authorize?parameters.
3. The OAuth provider navigates back to Contoso with https://contoso.com?code=foobar
4. Contoso clears the code from the URL bar, navigating to https://contoso.com

When RFC 6749 was published, this flow would have included:

• Three navigations (1=>2, 2=>3, 3=>4)
• Two downloads of the browser-based application (1 and 3) - 4 would have hit the cache entry created by 1.

Compare to the implicit flow:

1. User navigates to https://contoso.com/
2. Contoso redirects the user to the OAuth provider https://oauth.example/authorize?parameters.
3. The OAuth provider navigates back to Contoso with https://contoso.com#token=foobar
4. Contoso clears the code from the URL bar, navigating to https://contoso.com

When RFC 6749 was published, this flow would have included:

• Two navigations (1=>2, 2=>3)
• One download of the browser-based application (1) - 3 would have hit the cache entry created by 1, and 4 does not create a network request.

The document as it currently stands seems to recommend the authorization code flow as described by RFC 6749 (with query response). In today's world, that flow includes:

• Two navigations (1=>2, 2=>3)
• Two downloads of the browser-based application (1 and 3) - 4 does not make a network request.

Microsoft Entra (and other OpenID Connect providers) rely on the OAuth 2.0 Multiple Response Type Encoding Practices
standard and use the authorization code flow in combination with response_mode=fragment. That looks like this:

1. User navigates to https://contoso.com/
2. Contoso redirects the user to the OAuth provider https://oauth.example/authorize?parameters.
3. The OAuth provider navigates back to Contoso with https://contoso.com#code=foobar
4. Contoso clears the code from the URL bar, navigating to https://contoso.com

This flow includes:

• Two navigations (1=>2, 2=>3)
• One download of the browser-based application (1) - 3 would have hit the cache entry created by 1, and 4 does not create a network request.

Problem summary:

1. The document as it currently stands (without mention of response_mode=fragment) recommends a version of OAuth for browser-based apps that is less performant than the implicit flow recommended by RFC 6749.
2. The historic note only mentions one of the two reasons RFC 6479 recommended the implicit flow for browser based apps. Those two reasons are: reduced navigations AND reduced downloading.

Suggestions:

• The document should definitely mention response_mode=fragment. The document should probably either recommend or recommend against response_mode=fragment (I think: recommend).
• The historic note should explain both the motivations for the implicit flow and why neither applies (session history AND response_mode=fragment).

[aaronpk]

Thanks for the details.

Just to note, response_mode=fragment only applies to the third architectural pattern (section 6.3), since the other two are server backend flows.

The document should definitely mention response_mode=fragment. The document should probably either recommend or recommend against response_mode=fragment (I think: recommend).

It seems like your suggestion on oauthstuff/draft-ietf-oauth-security-topics#97 was to include a mention that this response mode is also susceptible to one of the attacks on the implicit flow. Did you mean to say that the Browser BCP should also not recommend response_mode=fragment then?

The historic note should explain both the motivations for the implicit flow and why neither applies (session history AND response_mode=fragment).

Can you suggest a sentence to include that describes why response_mode=fragment doesn't apply anymore?

[aaronpk]

Hi @will-bartlett just wanted to check on this again