Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

["Brock Allen" <[e-mail]>]

Hello all --

I also have some thoughts/feedback on this document.

Personally I agree with some of the conclusions, but as it stands I think the document's main conclusion that code flow is the real solution is not sufficiently convincing.

I would like to see a brief summary of the current concerns (much like RFC8252 does) so we have context before the document just jumps to what a best practice is. The reason I bring this up is that generally the concept of "best practice" is meaningless without context. I think stating that code flow is best practice without motivation seems somewhat "cart before the horse".

I think just a short blurb about the desire to eliminate the access token from being delivered in the URL, and the current attacks against doing so would be helpful (showing attacks is super important in making this "real"). I guess this would make the most sense in section "4. Overview" prior to the list of "best practice" conclusions.

Section "7.8. OAuth Implicit Grant Authorization Flow" does try to get into specifics, but many of the points seem confused (or at least confuse me) and/or the conclusion that code flow is the only approach seems misleading. For example:

"The Implicit Flow cannot be protected by PKCE [RFC7636] (which is required according to Section 6), so clients and authorization servers MUST NOT use the Implicit Flow for browser-based apps."

This is specious. The threat is the token is in the URL, not that implicit clients can't use PKCE. So perhaps the document should explain the variety of mitigations, not just one? While code flow is one, using CSP and the browser history API to remove the token from the URL is another. Elsewhere in the document the use of CSP is a "SHOULD". That's great, but using CSP can be and is used today, and doesn't necessitate code flow.

"OAuth 2.0 provides no mechanism for a client to verify that an access token was issued to it, which could lead to misuse and possible impersonation attacks if a malicious party hands off an access token it retrieved through some other means to the client."

Sure, but OIDC does provide a mitigation for this (even with implicit). So perhaps it should be offered as a suggestion as well? I did see the point that with code flow id_token validation could instead rely upon the token endpoint, but the client still has other work to do (namely around PKCE). That's just trading one bit of work for another, not a clear cut reason to use one flow over another.

"Supporting the implicit flow requires additional code, more upkeep and understanding of the related security considerations, while limiting the authorization server to just the authorization code flow simplifies the implementation."

As offered by someone else already, this is opinion and not objective. IMO, this diminishes the potential of this document.

"If the JavaScript application gets wrapped into a native app, then [RFC8252] also requires the use of the authorization code flow."

Given how many browser dependencies SPA apps tend to have, is this really common? In all my years building both, I've never seen it.

"Historically, the Implicit flow provided an advantage to single-page apps since JavaScript could always arbitrarily read and manipulate the fragment portion of the URL without triggering a page reload. Now with the Session History API (described in "Session history and navigation" of [HTML]), browsers have a mechanism to modify the path component of the URL without triggering a page reload, so this overloaded use of the fragment portion is no longer needed."

While this section is intended to indicate the existence of the history API is a reason to move away from implicit, it's also what can be used to protect token exposure in the URL, which I think weakens its point. As a section, to me, it seems unnecessary.

The push to a single flow (for consistency) is a marginal motivation, and I agree with that theme in the document.

Much of the other guidance in this document is already covered elsewhere (e.g. RFC6819). I don't know if the goal of the document is to reproduce those existing recommendations (as a contrast RFC8252 does not and mainly focuses on what's unique to the native scenario).

I can't quite tell the real motivation for this "best practice" document. If it's trying to give guidance for browser-based JS apps, then perhaps it should be enhanced to give guidance for the existing implicit flow, as well as suggesting code flow? But if the real motivation is just to kill off implicit flow then more needs to be done, IMO.

Finally, my last real concern (which is why I'm pushing back so much on code flow), is that this implies refresh tokens in the browser. My sense is that given the danger of this, the original OAuth2 RFC (via the implicit flow) was designed to limit the client's ability to obtain new access tokens based on the user's authentication session at the AS (via a cookie). Allowing refresh tokens now means that a successful attacker has unfettered ability to do this (beyond just an access token's lifetime). And yes, CSP is mentioned as a mitigation to protect the refresh token, but it was already necessary to protect the access token, so CSP is not the only mitigation. What's missing is strong guidance for token servers to provide mechanisms to limit the lifetime of refresh tokens for these high risk client scenarios. I have a suspicion that many existing token servers do not have such features, and this would imply more features mandated for the token servers (beyond PKCE for example).

Having said all of these things, I am all for using code flow. I just would like there to be more clear rationale. My comments above were the various counter arguments I was thinking while reading this document, and given how many of these I came up with I was left feeling unconvinced (as I already mentioned).

Thanks for reading this far, and thanks for putting forth the document.


-Brock

On 11/6/2018 5:14:05 AM, Aaron Parecki <[e-mail]> wrote:
Thanks Hannes,

Since I wasn't able to give an intro during the meeting today, I'd like to share a little more context about this here as well.

At the Internet Identity Workshop in Mountain View last week, I led a session to collect feedback on recommendations for OAuth for browser based apps. During the session, we came up with a list of several points based on the collective experience of the attendees. I then tried to address all those points in this draft.

The goal of this is not to specify any new behavior, but rather to limit the possibilities that the existing OAuth specs provide, to ensure a secure implementation in browser based apps.

Thanks in advance for your review and feedback!

Aaron Parecki
aaronpk.com [http://aaronpk.com]



On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig <[e-mail] [mailto:[e-mail]]> wrote:

Hi all,

Today we were not able to talk about draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth 2.0 for Browser-Based Apps".

Aaron put a few slides together, which can be found here:
https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf [https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf]

Your review of this new draft is highly appreciated.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
OAuth mailing list
[e-mail] [mailto:[e-mail]]
https://www.ietf.org/mailman/listinfo/oauth [https://www.ietf.org/mailman/listinfo/oauth]

--

----
Aaron Parecki
aaronparecki.com [http://aaronparecki.com]
@aaronpk [http://twitter.com/aaronpk]

_______________________________________________ OAuth mailing list [e-mail] https://www.ietf.org/mailman/listinfo/oauth