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

[Torsten Lodderstedt <[e-mail]>]

Hi Brock,

> Am 09.11.2018 um 21:22 schrieb 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.
> 

I agree, justifications are needed. As draft-ietf-oauth-security-topics-09 provides those justifications, I suggest to add suitable references here. 

> 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.“

Don’t understand the wording either. The text should state that the implicit cannot detect token injection.

> 
> 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.

Helps to prevent leakage, not injection in the authorization response. 

> 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).

This is about token replay detection at the RS. What mitigation does OIDC provide here? 

> 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).

The implicit grant was not equipped with the ability to issue refresh tokens simply because the working group didn’t want them to end up in the browser history, leak through open redirectors etc. This is different with code since tokens travel directly through a TLS protected connection.  

> Allowing refresh tokens now means that a successful attacker has unfettered ability to do this (beyond just an access token's lifetime).

First of all the AS decides whether it issues refresh tokens or not. Having the ability does not mean the AS must do it. If you feel it’s safer to not do it. Fine. It’s still possible to refresh your access tokens the way you mentioned above by sending another authorization request to the AS. 

But let’s assume for a moment the AS, based on its risk assessment, decides to issue refresh tokens. Can you please explain how an attacker will get access to this tokens? Especially what the expected strength of the attacker would need to be? 

I would also like to understand how a refresh token is any different from a long living cookie in the browser and what you think is the big difference to mobile apps when it comes to refresh token handling. 

> 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).

Good point! I will add text on refresh protection to the Security BCP. Limiting the refresh tokens lifetime, rotating them on every refresh (allowing the AS to detect replay), binding refresh tokens to certs etc. 

> 
> 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.

Thanks for your feedback. 

kind regards, 
Torsten,

> 
> -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
>> 
>> 
>> 
>> On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig <[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
>> 
>> 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]
>> https://www.ietf.org/mailman/listinfo/oauth
>> -- 
>> ----
>> Aaron Parecki
>> aaronparecki.com
>> @aaronpk
>> 
>> _______________________________________________ OAuth mailing list [e-mail] https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth