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

"Brock Allen" <brockallen@gmail.com> Fri, 18 May 2018 20:43 UTC

Return-Path: <brockallen@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 F182712E03C for <oauth@ietfa.amsl.com>; Fri, 18 May 2018 13:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_PASS=-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 2cWl-JCbtv7M for <oauth@ietfa.amsl.com>; Fri, 18 May 2018 13:43:21 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 E0B0E12DFDB for <oauth@ietf.org>; Fri, 18 May 2018 13:43:20 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id f5-v6so12004155qth.2 for <oauth@ietf.org>; Fri, 18 May 2018 13:43:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:cc:in-reply-to :references:user-agent; bh=gyoDBEFbGpBLD5qNcWh4San+UL5glOsYzhfUCmx4OlE=; b=Mw2WNP6jt6oAKEJb/2MKpmg5ucmIhTjcryPGgXlH25xXSINyvT9wpz7cV+dUyqugK/ 9ocpi1Tzxcio2uCLPKdM5gIa8CGF46IDqq70csvJ16Xpmqc01UQmIrLeynkhvTi49fUR XT3rVf42GTM6oO1v87PoeLsF4lOWK8Fq5mO/tFhCanrxEWj+Twv0YrYVR7KpREIKsrxB FQ03OrGp151E1oWuBuGgTKcsegoF5Lu5jXyMrNW43AlvKlI3H4FPImnblMfSAyXI70lw 8Zl/Y82UPcIEDw0n5jlWxVuyl2tyTyXYzoL8pz4b2v/svaoINqCrj5vi2ox+plSXx6KW fkRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :in-reply-to:references:user-agent; bh=gyoDBEFbGpBLD5qNcWh4San+UL5glOsYzhfUCmx4OlE=; b=UdpfrGXtLzb2qEBTTx7MfUx7LMGx6JKAsnamc7ZVRlFhYIutzkMbc0vcYgrxoZdDoq qi8UJDHZfRLCZtTf6Qq/If4IQq83DmKzMe9o9L2/WRf6NoSOqJYkMxj4qBDiZ0cEvAl+ 075k0GHNih56/Hq35m0MRt+LEX78OC68i1YkAFy3Je3fuYXBIEDhtcF2zlMOeqvZvqUj V9uyuW55cR9lKxSyFrNdc5tpfNZ3Lk7z0tV9kXpE0CNDG10rH+3B+dNBm8bA/m77ARMh GfBRUbzKJcvCvfBKjtW6bocKV0FcuHwuBh4+zdXjHY768AqP6xWa8pBgkuOZIIpBYwcd gHWg==
X-Gm-Message-State: ALKqPwcdDX9BhAvCdEAn/OZApxU6/vtxnLqj3AD/Sd2IBtYbfkqSFbMV 6W0tg/s2uMGLGROsk7NuDP8vD0xx
X-Google-Smtp-Source: AB8JxZqpW4axcRGTC3ZDhmQWrquElMB+WUADyITQlS820MxQk1w0cTY20ZChoWXCvjPC4b2uCfo8Zw==
X-Received: by 2002:ac8:303d:: with SMTP id f58-v6mr10549507qte.140.1526676199850; Fri, 18 May 2018 13:43:19 -0700 (PDT)
Received: from [10.0.1.2] ([24.38.185.147]) by smtp.gmail.com with ESMTPSA id f67-v6sm5854121qkb.77.2018.05.18.13.43.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 13:43:19 -0700 (PDT)
Content-Type: multipart/alternative; boundary="----=_NextPart_8441201.228505881278"
MIME-Version: 1.0
Date: Fri, 18 May 2018 16:43:17 -0400
Message-ID: <bbf44eca-7d78-4080-a803-367165fb7d1c@getmailbird.com>
From: "Brock Allen" <brockallen@gmail.com>
To: "David Waite" <david@alkaline-solutions.com>
Cc: "John Bradley" <ve7jtb@ve7jtb.com>, "Hannes Tschofenig" <hannes.tschofenig@arm.com>, "" <oauth@ietf.org>
In-Reply-To: <E51DC05D-1FB4-4C36-B309-3EF667F3E808@alkaline-solutions.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> <E51DC05D-1FB4-4C36-B309-3EF667F3E808@alkaline-solutions.com>
User-Agent: Mailbird/2.5.8.0
X-Mailbird-ID: bbf44eca-7d78-4080-a803-367165fb7d1c@getmailbird.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/BejzDh0ZaBxq8YTbA7cDNs94Dls>
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 20:43:23 -0000

We're basically on the same page, I think. 

I Was just coming from the perspective that once you've solved the iframe problem (say via a library), then it's six and one, or half a dozen and another, so to speak. Of course if the spec were redone today, it would look different and able to take into consideration what we have available today.

But you mention a 10-minute only access token. Without a refresh token, then you do have to resort back to the iframe, and then we're back at square one. But again, I'm still agreeing with you :)

As for prompt=none and the OP/AS wanting to set static policy to prevent iframes (presumably you mean with XFO/CSP), I don't see that as a problem. In my experience, those response headers don't apply when the response is just a 302 back to the redirect uri. They only are take effect when the response is rendering HTML. So you can set those globally in your OP/AS and it can still handle prompt=none properly. Unless I'm misunderstanding your last point.

-Brock

On 5/18/2018 2:21:06 PM, David Waite <david@alkaline-solutions.com> wrote:


On May 18, 2018, at 11:55 AM, Brock Allen <brockallen@gmail.com [mailto: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