Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

Aaron Parecki <aaron@parecki.com> Wed, 24 July 2019 20:15 UTC

Return-Path: <aaron@parecki.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE4C1205FE for <oauth@ietfa.amsl.com>; Wed, 24 Jul 2019 13:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Yea5UeliVP8 for <oauth@ietfa.amsl.com>; Wed, 24 Jul 2019 13:15:01 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550911205F8 for <oauth@ietf.org>; Wed, 24 Jul 2019 13:15:01 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id s7so92195466iob.11 for <oauth@ietf.org>; Wed, 24 Jul 2019 13:15:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ekwIdtny8wQRn+oEhlxXawPmpHdX8ig9PsEjOd7RLsQ=; b=Gkex64EGerZHRSJtO1HFARpUGNwMlw7mC67/9z4w7XhOQaS1TPOlUzIy3p+BSSA391 u2Pe0mfHWdgRyRYyuQxgaFeN+xureBAIPbu7iGC0Ef9JfyHa7OJVyiVArEtjiOcqDwp2 xPs/xC6L/euAwSXjnqK0E1s8eZe/fw7MNqHnAT3G4OOA7jLF4W7I0+kpcMbRrWxGDJmf kJyAXWhVHtsWIgh2MazfJlp5UQyELM4BfIakkLoxi70TofzI9Qs/51y6QVKlET22ldWi IozzcG8erQw1T+r7BuiY5sTq7Ps4ioKgM73UZIArH1M5vGM/gk7h8lFPsl0MIn1rzBQP Iedw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ekwIdtny8wQRn+oEhlxXawPmpHdX8ig9PsEjOd7RLsQ=; b=VqZJ9//lCOqipZJrflqEiqSa+WfJDc2BH80nCPcJbw7Z56hgky4vckFDT5lr26yU6u 46vQ/Te2EuFQt1VAs+Z3Q8CBRAZuJN80ezsFCzo6cK/Cp7Ge6UWpUJefdZS08z3Flokt g57PPV5a85Ew226SJN1+DeMMZYUDbwz61iAv/qk0KHwrYFNZJF1q6MkLYZFKoZPcyZ+U YycU4qh5iKowlPmjxP5ih8OYrjLJ/oRDolfZeFJbJSP4aM+xRYwnCOQqu5qp8r/zEhZm bInxOW2qJmqtDypKgSZ1+TUIUYe4fyRc+4dfUYGXAfbq7bLfvOrlJeNjIYAPt6gwQoAP 1cDw==
X-Gm-Message-State: APjAAAUuhs2FaeEUhLfwd2XBjShB8fhvR7GkRh7xbmRIA2IMythbS3PR iVXkrnl9vv84k+0nePELqyJJIgSRP9wSmw==
X-Google-Smtp-Source: APXvYqwWFD83aIpGtNzOObj6Ci2NGJSSyRZknJIUukXErhTyjaZRLvMfi8O3txGQif+NSyvORZJVLQ==
X-Received: by 2002:a05:6638:303:: with SMTP id w3mr32816234jap.103.1563999300192; Wed, 24 Jul 2019 13:15:00 -0700 (PDT)
Received: from mail-io1-f54.google.com (mail-io1-f54.google.com. [209.85.166.54]) by smtp.gmail.com with ESMTPSA id e84sm56908965iof.39.2019.07.24.13.14.59 for <oauth@ietf.org> (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jul 2019 13:14:59 -0700 (PDT)
Received: by mail-io1-f54.google.com with SMTP id g20so92297821ioc.12 for <oauth@ietf.org>; Wed, 24 Jul 2019 13:14:59 -0700 (PDT)
X-Received: by 2002:a6b:6e01:: with SMTP id d1mr6177884ioh.156.1563999299241; Wed, 24 Jul 2019 13:14:59 -0700 (PDT)
MIME-Version: 1.0
References: <CAGBSGjqVV3jJaXEX28N_fKbLSp3ijzb34N9NrZwZ+ZNXwXGKAg@mail.gmail.com> <0C094925-1429-46ED-8CF6-0D7B8DFB332F@lodderstedt.net> <CA+k3eCT5eG=S9AjM7Ss=DwHvsjwnriuZC3_yMxhrUaJXf2-vrw@mail.gmail.com> <99169CD8-F415-43CB-9F93-D779E5A15592@alkaline-solutions.com> <1903519861.188545.1563954610968@mail.yahoo.com>
In-Reply-To: <1903519861.188545.1563954610968@mail.yahoo.com>
From: Aaron Parecki <aaron@parecki.com>
Date: Wed, 24 Jul 2019 16:13:55 -0400
X-Gmail-Original-Message-ID: <CAGBSGjpXrE+s2PXv8yMBCpbYsJXtF=m3t-sfbVrD3Uy7NV6EDQ@mail.gmail.com>
Message-ID: <CAGBSGjpXrE+s2PXv8yMBCpbYsJXtF=m3t-sfbVrD3Uy7NV6EDQ@mail.gmail.com>
To: Tomek Stojecki <tstojecki=40yahoo.com@dmarc.ietf.org>
Cc: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, David Waite <david@alkaline-solutions.com>, OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a90f29058e72f611"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Enz63JOw_y4KTKwAHJsnROlrZHA>
Subject: Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2019 20:15:08 -0000

*whew* this is a lot of feedback. I will try to address all of these points
in this thread.

On Mon, Jul 22, 2019 at 9:30 AM Torsten Lodderstedt <torsten@lodderstedt.net>
wrote:

1) This BCP should not be limited to public clients. Your BCP itself
> already describes an architecture where the OAuth client is a backend that
> may be a confidential client (see section 6.2 for an example). The text of
> the BCP generally seems to be inconsistent regarding oauth client types.
> I suggest to remove the second part of the first paragraph of the abstract
> (“and should not be issued a client secret when registered.") and other
> statements limiting the BCP to public clients.


Agreed, this was a holdover from before I added the section that describes
the confidential client architecture option. I've updated this accordingly.

2) Regarding architectures: I think this BCP should focus on
> recommendations for securely implementing OAuth in the different potential
> architecture. I don’t think we should get into the business of recommending
> and assessing other solutions (e.g. section 6.1.).


This section was originally added from a discussion on the list, I believe
it was actually Torsten's suggestion:
https://mailarchive.ietf.org/arch/msg/oauth/JoEjvUrwE3pBPJI1olkEIR7ov9Q The
section was later modified and expanded based on feedback from the meeting
in Prague.

Although taking out "and OpenID Connect" from the sentence quoted above
> might be more appropriate and alleviate some confusion.


I will remove this, since this document is supposed to be focusing on OAuth
anyway.

3) The naming in section 6 focus on the ways the JS could be served. I
> personally think the more important aspect is the architecture of the
> overall application.



I suggest the following changes:
> - 6.2. Apps Served from a Dynamic Application Server -> SPA with backend
> - 6.3. Apps Served from a Static Web Server -> SPA without backend


I agree, but I'd like to continue to avoid using the term "SPA," so I'll
expand it out to "JavaScript Applications with a Backend".

4) I don’t understand why your BCP distinguishes 1st and 3rd party apps.
> Neither the Native apps BCP nor security BCP do so and need to.


This was part of the original brainstorming of the document at IIW in
October, because many of us were worried about people deploying "creative"
solutions in first-party app situations such as iframes or using the
password grant. The intent was to be explicit about using the OAuth
authorization code flow rather than password or an iframe solution even for
first-party apps.

5) Section 9.8 seems to duplicate portions of the Security BCP (while not
> giving the complete threat model) - what is the benefit of duplicating this
> text?


The intent here is to explicitly point out the issues with returning access
tokens in the front channel, in a way that is easy to find if someone is
looking for "what's wrong with using the implicit flow". I'd be happy to
shorten these to summaries and link out to the security BCP for the
details, but I do think it's valuable to have these called out in this
document.

6) I think the BCP would benefit from a refactoring. One idea would be to
> first state the problem with implicit and give general recommendations
> (PKCE and so on). The latter part could get into details of access and
> refresh token protection in the context of different SPA architectures
> (mTLS, CORS for CSRF prevention, …).


One reason I didn't want to go with this approach is it kind of reinforces
the assumption that implicit flow == browser apps. Instead of defining the
BCP in terms of what *not* to do, I wanted to start with the
recommendations for what you *should* do when building a browser-based app,
and eventually get to describing why not to use the implicit flow.

On Tue, Jul 23, 2019 at 12:25 AM Leo Tohill <leotohill@gmail.com> wrote:

Is this BCP supposed to be all about the architecture where the browser
> holds the token(s)?


I believe that was the original intent, but then we wanted to call out the
case that you can actually have a SPA where the tokens don't live in the
browser and that may be a better choice for you.

On Wed, Jul 24, 2019 at 3:50 AM Tomek Stojecki <tstojecki=
40yahoo.com@dmarc.ietf.org> wrote:

Finally and sorry if this is off-topic, why isn't this discussion taking
> place in github? Aaron has uploaded the document there. This medium, while
> good for some things, seems to have a lot of shortcomings for this sort of
> discussion and review.


I would *love* to have this discussion on GitHub with individual GitHub
issues for each conversation thread, since it would be much easier to keep
track of when a particular conversation has been resolved. But my
understanding is that only the mailing list is the "official" or "on the
record" medium, so discussion has to happen here.

The changes mentioned here are now pushed to my GitHub version.

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>



On Wed, Jul 24, 2019 at 3:50 AM Tomek Stojecki <tstojecki=
40yahoo.com@dmarc.ietf.org> wrote:

> I agree that 6.1 takes too broad of a swipe, but I'd say with same-site
> cookies and (sadly) without token-binding, the suggestion to use cookie
> based session following oauth/oidc auth is a good one and should be
> incorporated perhaps in 6.2?
>
> Leo sums it up well here:
> > We need to be clear on the distinction between browser based apps that
> hold the token(s) in the browser space, vs. those that don't.  I agree that
> with this "common domain" architecture, the tokens should not be held in
> the browser, but it doesn't follow that oauth should not be used at all.
>
> Finally and sorry if this is off-topic, why isn't this discussion taking
> place in github? Aaron has uploaded the document there. This medium, while
> good for some things, seems to have a lot of shortcomings for this sort of
> discussion and review.
>
> Thanks,
> Tomek
>
>
> On Wednesday, July 24, 2019, 04:14:14 AM GMT+2, David Waite <
> david@alkaline-solutions.com> wrote:
>
>
>
>
>
>
>
> > On Jul 23, 2019, at 12:47 PM, Brian Campbell <bcampbell=
> 40pingidentity.com@dmarc.ietf.org> wrote:
> >
> >
> >
> > On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
> >>
> >> 2) Regarding architectures: I think this BCP should focus on
> recommendations for securely implementing OAuth in the different potential
> architecture. I don’t think we should get into the business of recommending
> and assessing other solutions (e.g. section 6.1.). Just to give you an
> example: Section 6.1. states
> >>
> >> "OAuth and OpenID Connect provide very little benefit in this
> deployment scenario, so it is recommended to reconsider whether you need
> OAuth or OpenID Connect at all in this case.”
> >>
> >> Really? What experiences is this statement based on? In my experience,
> sharing the same domain == host name tells you nothing about the overall
> architecture of a certain deployment. There may be several reasons why
> OAuth could be good choice in such a scenario, e.g. security considerations
> (since your common domain is just a proxy server encapsulating a whole
> universe of systems) or even modularity as an architecture principle.
> >>
> >> I suggest to remove section c. and to rephrase the second paragraph of
> the abstract.
> >
> > I believe the experiences that the statement is based on are the
> predominant practice over the course of much of the history of the web of
> using a cookie to maintain an authenticated HTTP session in web
> applications. When the script of the browser-based application is served
> from a domain that can share cookies with the domain of the API, then
> cookies can still be used to authorize requests (even if those requests are
> API calls rather than full page HTTP request/response). And I do believe
> that's likely a better decision in a lot of such cases.
> >
> > That authenticated HTTP session may be establish from a
> username/password form submission, FIDO/WebAuthn, or whatever.  Even as a
> result of an OpenID Connect flow. Or even SAML for that matter. But the the
> requests after that are authorized by the cookie.
> >
> > I think there's a tendency to assume because SPA style apps make API
> calls, they simply must use OAuth. Because API implies OAuth in the minds
> of many (which is a sign of its success). But OAuth isn't necessarily the
> only thing that can be used for API authorization. Cookies work too. I
> think/hope that's what Section 6.1. is getting at - providing some
> potential guidance that OAuth might not necessarily be the right choice in
> those cases where a common domain allows for a cookie. Perhaps the text in
> that section could be phased in a different or better way, but I think its
> useful to have some mention of in this document.
> >
> > Although taking out "and OpenID Connect" from the sentence quoted above
> might be more appropriate and alleviate some confusion.
> >
> >
>
> Perhaps it should be turned into a stated document assumption (that the
> reader has decided to use OAuth) rather than guidance later in the document
> (that OAuth may not be the best fit)
>
> There is AFAIK no set of security considerations or best practices we can
> point to for “use some non-standardized system for acquiring and using
> cookies” or even “here’s a standard for acquiring and using cookies”.
> Omitting some of the moving pieces of OAuth might alleviate some security
> concerns, but also resurrect some other security issues. The most immediate
> example that comes to mind: using a HttpOnly cookie-as-token instead of an
> access token may mean that you can’t have injected scripts exfiltrate the
> token, but applying the access token was also a mitigation against browser
> CSRF for your APIs.
>
> -DW
> _______________________________________________
> 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
>