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 <aa...@parecki.com> 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 <hannes.tschofe...@arm.com
[mailto:hannes.tschofe...@arm.com]> 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
OAuth@ietf.org [mailto:OAuth@ietf.org]
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
OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
