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

Torsten Lodderstedt <torsten@lodderstedt.net> Sat, 01 December 2018 14:34 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 380A9127B92 for <oauth@ietfa.amsl.com>; Sat, 1 Dec 2018 06:34:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 mHzQerU0SXnf for <oauth@ietfa.amsl.com>; Sat, 1 Dec 2018 06:34:16 -0800 (PST)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.28]) (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 2827C128BCC for <oauth@ietf.org>; Sat, 1 Dec 2018 06:34:15 -0800 (PST)
Received: from [80.187.81.0] (helo=[10.120.12.75]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1gT6LT-00008l-OC; Sat, 01 Dec 2018 15:34:11 +0100
Content-Type: multipart/signed; boundary="Apple-Mail-94040A08-79C2-4EC7-998C-66EF6E22EFFD"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: iPhone Mail (16B92)
In-Reply-To: <VI1PR0801MB21121BCD21DE8ABAF055E603FAAC0@VI1PR0801MB2112.eurprd08.prod.outlook.com>
Date: Sat, 01 Dec 2018 15:34:10 +0100
Cc: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <E0F62B7E-9C58-493A-BEFD-91D7441BB5BF@lodderstedt.net>
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>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/OxKgBOf9LQ_pA_ab6FNuK7_PKzQ>
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: Sat, 01 Dec 2018 14:34:20 -0000

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