Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

David Waite <david@alkaline-solutions.com> Fri, 18 May 2018 18:21 UTC

Return-Path: <david@alkaline-solutions.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 2C94B12D810 for <oauth@ietfa.amsl.com>; Fri, 18 May 2018 11:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 buqLiWMCTFLY for <oauth@ietfa.amsl.com>; Fri, 18 May 2018 11:21:06 -0700 (PDT)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 975A312D80E for <oauth@ietf.org>; Fri, 18 May 2018 11:21:06 -0700 (PDT)
Received: from [IPv6:2601:282:202:b210:b1c1:9dc5:ed80:9403] (unknown [IPv6:2601:282:202:b210:b1c1:9dc5:ed80:9403]) by alkaline-solutions.com (Postfix) with ESMTPSA id A43C931544; Fri, 18 May 2018 18:21:05 +0000 (UTC)
From: David Waite <david@alkaline-solutions.com>
Message-Id: <E51DC05D-1FB4-4C36-B309-3EF667F3E808@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A6FD39A7-5BA8-442C-8C02-54144559921F"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Fri, 18 May 2018 12:21:03 -0600
In-Reply-To: <5076c4e6-ae3f-4632-b133-146a04db7ec9@getmailbird.com>
Cc: John Bradley <ve7jtb@ve7jtb.com>, Hannes Tschofenig <hannes.tschofenig@arm.com>, oauth@ietf.org
To: Brock Allen <brockallen@gmail.com>
References: <ab42d84a-5f08-4600-aa36-92e73944cf6c@getmailbird.com> <VI1PR0801MB2112A6F8B47939F8748DEA43FA910@VI1PR0801MB2112.eurprd08.prod.outlook.com> <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <,895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> <MWHPR19MB1085FC4579E0A656BB78A8ABFA900@MWHPR19MB1085.namprd19.prod.outlook.com> <22977d8a-ead8-49fe-83c0-46c5c594ac40@getmailbird.com> <5aff03b3.1c69fb81.a01df.2946@mx.google.com> <0075D910-35DA-4B8B-A739-D57CF7A8765E@alkaline-solutions.com> <5076c4e6-ae3f-4632-b133-146a04db7ec9@getmailbird.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/AX1ccYLzzMimYdaXrCKQfadwMJI>
Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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, 18 May 2018 18:21:08 -0000


> On May 18, 2018, at 11:55 AM, Brock Allen <brockallen@gmail.com> wrote:
> 
> > I don’t believe code flow today with an equivalent token policy as you have with implicit causes any new security issues, and it does correct _some_ problems. The problem is that you immediately want to change token policy to get around hidden iframes and special parameters.
> 
> Hidden frames and special params -- are those really the main concerns with implicit?

They aren’t the only issues, no. The point was that you can use code flow instead of implicit, keep a 10 minute access token lifetime and no refresh token, and it doesn’t add new security concerns. The security concerns are around changing token policy once you are doing code flow, due to the execution environment of the browser.

The main initial motivation around implicit was client simplicity (plus it was rather early for CORS). Once you are implementing a second iframe-based approach to discretely retrieve updated access tokens, the simplicity argument doesn’t hold.

It is also an additional security consideration for the AS - ideally I want to reject my user authentication/consent content from being loaded in frames as a static policy, but now I need to allow it when prompt=none is set. This isn’t a policy recommended anyplace, just something the developers may have to argue with against the security people so that their app can have a halfway decent experience.

-DW

> I thought the access token being sent in the URL is a bigger concern, and that's why code+PKCE is a better approach.

> 
> -Brock