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

John Bradley <ve7jtb@ve7jtb.com> Mon, 03 December 2018 10:19 UTC

Return-Path: <ve7jtb@ve7jtb.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 5FA52130E19 for <oauth@ietfa.amsl.com>; Mon, 3 Dec 2018 02:19:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level:
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-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=ve7jtb-com.20150623.gappssmtp.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 MwqMIdz2CITd for <oauth@ietfa.amsl.com>; Mon, 3 Dec 2018 02:19:17 -0800 (PST)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 27A0C130DDA for <oauth@ietf.org>; Mon, 3 Dec 2018 02:19:17 -0800 (PST)
Received: by mail-wm1-x336.google.com with SMTP id s14so5147711wmh.1 for <oauth@ietf.org>; Mon, 03 Dec 2018 02:19:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JnjxzSZmuuWC7Dj9GWu5G23cbdkfZ94K6jDgl5KT+wQ=; b=o59AuVJm4YY7+Jd43Qe5OVuvXDlyqdNls7zOPgrwjrlDjAs3LnVxyPngshuaqxrJBi lUSwOEbqSmpS9MfewkpQ+ZZ+yDfD83hQLTPHHsbj1y3Vl/Fsamb9foK9krCgmSOQa68f ffaUtU6vY58YHPU7EkAbvTgdR5xdUE0/JXeQvJ1+93j+xyewpSOgev8A6uLEyxgyT46V Rs/WjXrdZitNupBbcAnL1ifTjE9kHorO2n7rDG9/RK9t3Ekh/iQ0Xyowe8RukVe00+hj UeQT9SNGkvGNIVc19Qjyck1v4xHa4UKAoNMGzS98NO/XZQBYvcmpV8X5gi+n1djdcJ/e HZ8A==
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=JnjxzSZmuuWC7Dj9GWu5G23cbdkfZ94K6jDgl5KT+wQ=; b=fwNC9Ri0ccWxErIogxN1NJmZgMlTkEiDNhCNKwRp+slx3Nk+HNyYRdannQpMqDqlke +owhEFTDPDomyImiEPaxVqZ8NvgtUhJaSgMyVMIMH3sg8R7YWPf3ZcDyrBoffRPEvwwV H7unjjiZRlpQfctrHPXdaFo/fQyarh5sp9zg1y1OiHJV7AQpPbzx/CJ8f19KhLvkqqow DzViEdFthDNhW1nINcgb40QZ6bCuvS7TqazDDi1fQ+4Bi/CqvS/b8cxeWjRFOGjLZ56c p+rqCEMcjJm9daj+c8AzmamO0DTCYJPTQHAyInUnm5VV6ZSUyjk1srIoZbxSafwHWmHG nwyw==
X-Gm-Message-State: AA+aEWYQsOtfhcSDSmbiP5lKOecH7fd1gjRwyWxzfyLhkG2Oi0JmHcGb cHIIVNHOMjkYuC+IjPeBJfvOrIiDaKWc9FsWRwEFRIeWtVg=
X-Google-Smtp-Source: AFSGD/U2snpz50lLYC4HxzaIKu9VFH2TBVb1anQfXVyCe3EYCpF8Dc6uTyuxtbvOMf6cyIcFKOBdEV0KUwp9z5u4rfI=
X-Received: by 2002:a7b:c1d7:: with SMTP id a23mr7309627wmj.48.1543832354932; Mon, 03 Dec 2018 02:19:14 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <CAGBSGjoVox6Ab274DbHfEBaXibk8OFeXy6g3SEXxRP1TauPBvQ@mail.gmail.com>
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Mon, 03 Dec 2018 11:19:06 +0100
Message-ID: <CAANoGhL0F4a0v1_8ROx8NqcjTA93rzgV=rWoUpwXPR6DR65yOw@mail.gmail.com>
To: Aaron Parecki <aaron@parecki.com>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, IETF oauth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001bdcfe057c1b7bb8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/KpT47WwiOAregiOiA8VCLaNoQns>
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 10:19:20 -0000

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>:
>>
>> 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>:
>>
>> 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>:
>>
>> 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>:
>> >
>> > 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
>> <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 listOAuth@ietf.orghttps://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
>>
>