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

Torsten Lodderstedt <torsten@lodderstedt.net> Mon, 03 December 2018 11:15 UTC

Return-Path: <torsten@lodderstedt.net>
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 06C2D130E4B for <oauth@ietfa.amsl.com>; Mon, 3 Dec 2018 03:15:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 qB1-q9wcA5bb for <oauth@ietfa.amsl.com>; Mon, 3 Dec 2018 03:15:24 -0800 (PST)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611E5128DFD for <oauth@ietf.org>; Mon, 3 Dec 2018 03:15:24 -0800 (PST)
Received: from [87.79.89.127] (helo=[10.2.11.3]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1gTmC8-0001t8-TV; Mon, 03 Dec 2018 12:15:21 +0100
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <7FEF0314-88F2-46C7-A22D-C794CC1BB6A0@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_269854A5-5C36-4009-AE1D-1F937CA52066"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Mon, 3 Dec 2018 12:15:19 +0100
In-Reply-To: <CAANoGhL0F4a0v1_8ROx8NqcjTA93rzgV=rWoUpwXPR6DR65yOw@mail.gmail.com>
Cc: Aaron Parecki <aaron@parecki.com>, IETF oauth WG <oauth@ietf.org>
To: John Bradley <ve7jtb@ve7jtb.com>
References: <VI1PR0801MB211299BED6B61582DC33B873FACB0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <CAGBSGjqHKVveZor-oKUWzsQ0Rg5Fk_d2dns_eQFqfvXJynyQaQ@mail.gmail.com> <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <CA+k3eCTjRWo-OF+Q=KotOJzfBw1uSe7w_bHWDhDKi3WRjQsH9Q@mail.gmail.com> <VI1PR0801MB21121BCD21DE8ABAF055E603FAAC0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <E0F62B7E-9C58-493A-BEFD-91D7441BB5BF@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> <df7c80be-477e-bb4a-cc29-edb233571a2f@ve7jtb.com> <A6E974DC-59C2-43E2-9534-CAD2EE695941@lodderstedt.net> <CAGBSGjoVox6Ab274DbHfEBaXibk8OFeXy6g3SEXxRP1TauPBvQ@mail.gmail.com> <CAANoGhL0F4a0v1_8ROx8NqcjTA93rzgV=rWoUpwXPR6DR65yOw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.101.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/JoEjvUrwE3pBPJI1olkEIR7ov9Q>
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: Mon, 03 Dec 2018 11:15:28 -0000

Interesting. Even on this list people felt to see that moving some logic to a backend could solve some of the problems raised. What I want to convey is: the solution to a problem in the OAuth space does not necessarily need to be found on the OAuth protocol level. That’s a best practice in the same way as some OAuth pattern. 

What I’m suggesting is a statement in the BCP like

—
Implementations MAY consider to move authorization code exchange and handling of access and refresh tokens to a backend component in order to fulfill their security goals. 

Security of the connection between code running in the browser and this backend component is assumed to utilize browser-level protection mechanisms. Details are out of scope of this document. 
—

> Am 03.12.2018 um 11:19 schrieb John Bradley <ve7jtb@ve7jtb.com>om>:
> 
> This is my point.  
> 
> From a security perspective we have a server based confidential client.   The fact that it has a angular or other JS UI protected by a cookie seems to not be especially relucent to OAuth.  
> 
> Perhaps from the developer point of view they have a JS SPA and the only difference to them is in one case they are including the OAuth client and in the other they are using a server based proxy. So they see it as the same.
> 
> Perhaps it is perspective. 
> 
> On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki <aaron@parecki.com wrote:
> In this type of deployment, as far as OAuth is concerned, isn't the backend web server a confidential client? Is there even anything unique to this situation as far as OAuth security goes? 
> 
> I wouldn't have expected an Angular app that talks to its own server backend that's managing OAuth credentials to fall under the umbrella of this BCP.
> 
> ----
> Aaron Parecki
> aaronparecki.com
> 
> 
> 
> On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
> the UI is rendered in the frontend, UI control flow is in the frontend. just a different cut through the web app’s layering 
> 
> All Angular apps I have seen so far work that way. And it makes a lot of sense to me. The backend can aggregate and optimize access to the underlying services without the need to fully expose them.
> 
> Am 02.12.2018 um 00:44 schrieb John Bradley <ve7jtb@ve7jtb.com>om>:
> 
>> How is that different from a regular server client with a web interface if the backed is doing the API calls to the RS?
>> 
>> 
>> 
>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>>> I forgot to mention another (architectural) option: split an application into frontend provided by JS in the browser and a backend, which takes care of the business logic and handles tokens and API access. Replay detection at the interface between SPA and backend can utilize standard web techniques (see OWASP). The backend in turn can use mTLS for sender constraining.
>>> 
>>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <torsten@lodderstedt.net>et>:
>>> 
>>>> IMHO the best mechanism at hand currently to cope with token leakage/replay in SPAs is to use refresh tokens (rotating w/ replay detection) and issue short living and privilege restricted access tokens.
>>>> 
>>>> Sender constrained access tokens in SPAs need adoption of token binding or alternative mechanism. mtls could potentially work in deployments with automated cert rollout but browser UX and interplay with fetch needs some work. We potentially must consider to warm up application level PoP mechanisms in conjunction with web crypto. Another path to be evaluated could be web auth.
>>>> 
>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <Hannes.Tschofenig@arm.com>om>:
>>>> 
>>>>> I share the concern Brian has, which is also the conclusion I came up with in my other email sent a few minutes ago.
>>>>> 
>>>>>  
>>>>> 
>>>>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Campbell
>>>>> Sent: Friday, November 30, 2018 11:43 PM
>>>>> To: Torsten Lodderstedt <torsten@lodderstedt.net>
>>>>> Cc: oauth <oauth@ietf.org>
>>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>>>>> 
>>>>>  
>>>>> 
>>>>>  
>>>>> 
>>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>>>> 
>>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen <brockallen@gmail.com>om>:
>>>>> > 
>>>>> > So you mean at the resource server ensuring the token was really issued to the client? Isn't that an inherent limitation of all bearer tokens (modulo HTTP token binding, which is still some time off)?
>>>>> 
>>>>> Sure. That’s why the Security BCP recommends use of TLS-based methods for sender constraining access tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2). Token Binding for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options available.
>>>>> 
>>>>>  
>>>>> 
>>>>> Unfortunately even when using the token endpoint, for SPA / in-browser client applications, the potential mechanisms for sender/key-constraining access tokens don't work very well or maybe don't work at all. So I don't know that the recommendation is very realistic.
>>>>> 
>>>>>  
>>>>> 
>>>>> 
>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
>>>>> 
>>>>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> 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