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

Leo Tohill <leotohill@gmail.com> Tue, 23 July 2019 04:25 UTC

Return-Path: <leotohill@gmail.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 EAA4112003E for <oauth@ietfa.amsl.com>; Mon, 22 Jul 2019 21:25:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 9BMV-a3Ys0Gn for <oauth@ietfa.amsl.com>; Mon, 22 Jul 2019 21:25:02 -0700 (PDT)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 6ACFD120018 for <oauth@ietf.org>; Mon, 22 Jul 2019 21:25:02 -0700 (PDT)
Received: by mail-pf1-x434.google.com with SMTP id c73so18425904pfb.13 for <oauth@ietf.org>; Mon, 22 Jul 2019 21:25:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XRobZwR4x6H53kWSHrHLMYdTuPHopzWo8mEZv3ArGhc=; b=E9K+mK4K9KPoQbNITKbq/+ccqgRY/4GgVMZAkd/yokgf7QkSt13lvQdRY3TklYYIGd WsoSQSbBJTjfuxG/3xxUlrlZ9LMDGocUoDUmbyvXwhLlRBLi1eLL9ELlKrxf+SypvTRa 7IrHk/n1m/NPe9Y6Ty6nTguTHJl51FNtBiryOeK1I7XRffdcIgVNZRvggD7v/ZYQWWq9 ib8NbEWnhCaLMl2WPq9uPeUDuxWwWnxnnqSPq/cSzUErkEhaGyB5p92I84KlIoaO+ExS jTk0fpaB817yBOts6IdAHPdq7h/FmeT+JIgXIkINY1zGFA1YIuOXwPntXh5O5cFsRn6q SVyA==
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=XRobZwR4x6H53kWSHrHLMYdTuPHopzWo8mEZv3ArGhc=; b=D11G6GIxdHSGK979+cN6cx9E4FyO5xVnrGX6xNAFbMGLu7vum6AYpvtMORdV84Rf/V NqKWU1Uhc9cpnfm5tc4OB4UIbfTcfs7c4+jnBhj9OsFdhbpPwkBaPwp1z3Ov0aKiBTy8 h6RlfCI9EjP/dorwIhg9fi2qd55wNlo4Zdug7Yjq/Rtdf5yr8RdDktbAr/DQvr4Q8CZo aj6kSOepjbziv4VtWHQSuv2qHgIzTeFCkkxyLADyK2pfXftVzrpw+PcdCZCijyatxrO0 9UecyY+mGKZ69KSpBAMs0LE0ebOqtF2SKFU1pHO9W25cuhM5+W7xhnVT9SxDj0gn82eV Spqw==
X-Gm-Message-State: APjAAAU9q+0fTV9JOE5HhrM9z13jM2+AwY9if2pR5WsDagTI/2NbHHVx TZq1z1HimwEOFfcWw8o4ry/LANYdR+f3/yeYFv9SQw0r
X-Google-Smtp-Source: APXvYqxprlIlVkZMGkE/KsgusIhnhkEeR+z3S7IuPZ8WQ1Nx804mIYCCncyxwxv+eKIsKaCcxPBrPaMnNJsvVXCzgsE=
X-Received: by 2002:a17:90a:338b:: with SMTP id n11mr79343322pjb.21.1563855901699; Mon, 22 Jul 2019 21:25:01 -0700 (PDT)
MIME-Version: 1.0
References: <CAGBSGjqVV3jJaXEX28N_fKbLSp3ijzb34N9NrZwZ+ZNXwXGKAg@mail.gmail.com> <0C094925-1429-46ED-8CF6-0D7B8DFB332F@lodderstedt.net>
In-Reply-To: <0C094925-1429-46ED-8CF6-0D7B8DFB332F@lodderstedt.net>
From: Leo Tohill <leotohill@gmail.com>
Date: Tue, 23 Jul 2019 00:24:50 -0400
Message-ID: <CABw+Fcuym5VBmbbfcYkySuad3rHi40txKB4v4jopaVoC+CDmZw@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Aaron Parecki <aaron@parecki.com>, OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000803595058e519336"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/-vdnqUg15p4i8Bsc3oI9V2T7Ak0>
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: Tue, 23 Jul 2019 04:25:05 -0000

I agree that there's a problem regarding the scope of this BCP .   Or at
least, I'm confused.

Is this BCP supposed to be all about the architecture where the browser
holds the token(s)?
If so, then

a) let's just put that out front and center: that's the context of this
BCP. That's what's meant by "browser-based application."
b) It really IS limited to public clients.
c) 6.2 simply doesn't belong: it is describing a different architecture.

If, on the other hand, 6.2 is to be retained, it needs to be rephrased from
saying the OAuth is not the right solution. Oauth can/will still be used,
but the token(s) will be used server side, not client/browser side.


- Leo




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

> Hi Aaron,
>
> thanks for your continued work on the topic.
>
> Here are some general remarks on the current revision:
>
> 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.
>
> 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 6.1. and to rephrase the second paragraph of
> the abstract.
>
> 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
>
> Note: even an SPA with a backend could use a static web server to serve
> the JS code.
>
> 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.
>
> 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?
>
> 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, …).
>
> kind regards,
> Torsten.
>
> > On 9. Jul 2019, at 01:03, Aaron Parecki <aaron@parecki.com> wrote:
> >
> > Hi all,
> >
> > I've just uploaded a new version of oauth-browser-based-apps in
> preparation for the meeting in Montreal.
> >
> > https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02
> >
> > This draft incorporates much of the feedback I've received over the last
> couple months, as well as what we discussed at the last meeting in Prague.
> >
> > The primary change is a significant rewrite and addition of Section 6 to
> highlight the two common deployment patterns, a SPA with and without a
> dynamic backend.
> >
> > Please have a look and let me know what you think. I have a slot in the
> agenda for Montreal to present on this as well.
> >
> > Thanks!
> >
> > ----
> > Aaron Parecki
> > aaronparecki.com
> >
> > _______________________________________________
> > 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
>