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

Daniel Fett <danielf+oauth@yes.com> Fri, 16 November 2018 07:58 UTC

Return-Path: <danielf+oauth@yes.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 798BC127133 for <oauth@ietfa.amsl.com>; Thu, 15 Nov 2018 23:58:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yes.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 DYWDnIDe1HdJ for <oauth@ietfa.amsl.com>; Thu, 15 Nov 2018 23:57:58 -0800 (PST)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 12C91124D68 for <oauth@ietf.org>; Thu, 15 Nov 2018 23:57:58 -0800 (PST)
Received: by mail-wr1-x42d.google.com with SMTP id 96so6955738wrb.2 for <oauth@ietf.org>; Thu, 15 Nov 2018 23:57:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=z6XOXFswh/nzN4frwBcVzVDzFmObUIACkFXco/BtmDc=; b=ldI4LKcZvbHL15L12AeO6BlEO/YyHm/wJhiCKZDI0+Ufk/sciiXuZP0g/W+UIYFYvh VQnp/9SikuCqh/Evxh97jWhx9r5j49lcRmVsd2jfIc2pn0jOtBb0sACyH1uF5DnX5Jsl mlZXN9a0Jyi609LSghN+H86sgj6gdZc13A5b7S12kds8ZS/08Mh9mfg6nBrEhr21ycjd gozIOmcwMSRQkxvZXVjg6iydlxjYt4Cc5HavTZzODKbJ4lVlnDT7Lm09dcL1GnjzNKir 5j1RseoaGDYCUIt7BEjCgSWrmSOSt7fvlun9ipNELK6M+R6B6DzM94HtfUxFiqd2FTK/ dLcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=z6XOXFswh/nzN4frwBcVzVDzFmObUIACkFXco/BtmDc=; b=av6xrt4aEs/bU3C8QMV4sRSl3qjsxHxZsptazpo645mgalN2wAQkV/XVLkHjQWuMEn 95xCnEbeinE3fIDINMZ1OHT7Vmn5JxvI1ElwxN/lNaEO3H8zYudDi2ON8ortwLZusoas yxY/aGVA2mR6WV/Z5HaGNx58NC3GvXOyPRPy62Vqoi1L+eZyOZ0w0eFk5m3Ww4JKhk+N 3sGJpEVWmwLHa2+lTzGGgwmaaAj4p+BO/D2aJxprPkXxWreilqz9ELnLepQt0YC8cfkO t8QTQrLdU5q30uBWjOgurshMRQnJX3ri2BX4BOAkZ3fSUo6sHR9iPwKTnqQpDT64dGtK +47g==
X-Gm-Message-State: AGRZ1gKQceuUgFee5k4jdoYYWyluv1yrB+eG+d13RpBeQwaEZIp16gXz rjVlyRJyKDwpNBzMv2XgluCDoPaH/4w=
X-Google-Smtp-Source: AJdET5eP2MexezOahqB2Eco+GgqnIruD5nPf8A91BoSorcylKmZoeywmSeg0Mcxn1xUiQWdjC9VnjQ==
X-Received: by 2002:adf:db86:: with SMTP id u6-v6mr8608638wri.165.1542355076002; Thu, 15 Nov 2018 23:57:56 -0800 (PST)
Received: from ?IPv6:2003:c1:4f2e:1600:cc33:a3af:4584:e7de? (p200300C14F2E1600CC33A3AF4584E7DE.dip0.t-ipconnect.de. [2003:c1:4f2e:1600:cc33:a3af:4584:e7de]) by smtp.gmail.com with ESMTPSA id t5sm2915745wmd.15.2018.11.15.23.57.54 for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Nov 2018 23:57:55 -0800 (PST)
To: oauth@ietf.org
References: <VI1PR0801MB211299BED6B61582DC33B873FACB0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <CAGBSGjqHKVveZor-oKUWzsQ0Rg5Fk_d2dns_eQFqfvXJynyQaQ@mail.gmail.com> <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com>
From: Daniel Fett <danielf+oauth@yes.com>
Message-ID: <ef8353a0-3fb1-3428-d7dc-26a6b96ae22b@yes.com>
Date: Fri, 16 Nov 2018 08:57:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com>
Content-Type: multipart/alternative; boundary="------------0A5D8A178C11EA86A997216D"
Content-Language: de-DE
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/kOoEkcDqRPDHsPY3rvBt-EW_I1c>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
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: Fri, 16 Nov 2018 07:58:01 -0000

Hi all,

Am 09.11.18 um 21:22 schrieb Brock Allen:
>
> 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.

Could you please expand on what you are achieving with replacing the URL
using the history API? Removing the token from the browser's history, or
any protection beyond that?


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

Another aspect is that removing implicit as an option greatly simplifies
security analysis and formal proofs of security (of which I hope we will
see more instances in the future). If you look at it this way, it is
much more than an opinion and it is definitely objective.

- Daniel