Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
John Bradley <ve7jtb@ve7jtb.com> Sat, 01 December 2018 23:44 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 197FB130E67 for <oauth@ietfa.amsl.com>; Sat, 1 Dec 2018 15:44:44 -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 vp0Tf7imq60W for <oauth@ietfa.amsl.com>; Sat, 1 Dec 2018 15:44:40 -0800 (PST)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 7ED2E130E66 for <oauth@ietf.org>; Sat, 1 Dec 2018 15:44:40 -0800 (PST)
Received: by mail-ed1-x532.google.com with SMTP id z28so7765184edi.8 for <oauth@ietf.org>; Sat, 01 Dec 2018 15:44:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=mTlYtw7t7ep0X+FgTUDWxRe/U6VDkJQ8z5XZkGApnHc=; b=MBPT6MwHObADz1kzohFAqt3mmQIaKsYu0vOdkXA7uRtBUP9ezIiohb13//7qrkfxzq dVE9rMNLNfudLrluMXGitqhwhR4LwUtkRm+KNdusHmztsE0igFAgYPtBBWxV3b/97NBS h4d85tHZ3yXE8NYFXMJovAtcwHQiwJ2X2NyhcjsItBxTZBZt5HXIG0eLCKqg9boyW5ey KsNRXe3PoKYq3AHb8F90YYd3IeBMbxNuJPlGggy1nTC52+pI9Hs9zF4r3vpufx5mFZGw i6yVYoTHl/Fyd7tt2Zm8wKt2s6dWOFHz6vgveapq/GvxEXIhr46tbmYmbrgv6IgQG42G d+Jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=mTlYtw7t7ep0X+FgTUDWxRe/U6VDkJQ8z5XZkGApnHc=; b=UnrOuvB1SIrVD03bOAFRukt6PsarPrc+YCm/JPbAUU+7sO4bLCysjas3g3ncWLlPDz 8jomplG71j+ss+gTbOn0PUDit+Bjx3+j9c+63V4oD72DJ/gMIpXLOGRdC73w9oGje+OG ZIOZ9xkpdeMuD3Mw/Nu8wYxaHRFH9P+wsYWsoZgrq7oEkHxbiwMfTnRg11Wr4D+q8TwR 2m4wPLZW04078bUue6QbKiPRtpY7RivJBPe7YChqaxE8cm4Z+BQzL19b2xFP7/TNVXFb 4JTNVfVly1uKUT9rqRIydcEekpgZMFg3txiLjM1yiMKZdsNXcrEsfhLYOpwcyp3G8Fly JODQ==
X-Gm-Message-State: AA+aEWaG8eYIRF5GUSY/YhMIozSXAqx2wIlzFwa2FQtBxAK3ShSD3SG8 gneInCVeVDZHXm0Z1Kcj7GMYOEksnkmEag==
X-Google-Smtp-Source: AFSGD/Wm3BA3FHT1vobLQwq6lOB4kRZmP+FepXIVP9PTg2V9N+svqLUMuv5NhMVEuiT6zJc2ZUuCAg==
X-Received: by 2002:a17:906:138d:: with SMTP id f13-v6mr8571420ejc.176.1543707878001; Sat, 01 Dec 2018 15:44:38 -0800 (PST)
Received: from [10.38.11.6] ([212.92.123.75]) by smtp.gmail.com with ESMTPSA id c12sm2487578edi.52.2018.12.01.15.44.36 for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Dec 2018 15:44:37 -0800 (PST)
From: John Bradley <ve7jtb@ve7jtb.com>
X-Google-Original-From: John Bradley <VE7JTB@ve7jtb.com>
To: oauth@ietf.org
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>
Message-ID: <df7c80be-477e-bb4a-cc29-edb233571a2f@ve7jtb.com>
Date: Sat, 01 Dec 2018 20:44:37 -0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Thunderbird/64.0
MIME-Version: 1.0
In-Reply-To: <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------A81C86C0D638F27B4338D15C"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ItZ7SywRXMf86-hkh8ijdjVIvOs>
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 23:44:44 -0000
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 <mailto: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 <mailto: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 >>> <mailto:oauth-bounces@ietf.org>> *On Behalf Of *Brian Campbell >>> *Sent:* Friday, November 30, 2018 11:43 PM >>> *To:* Torsten Lodderstedt <torsten@lodderstedt.net >>> <mailto:torsten@lodderstedt.net>> >>> *Cc:* oauth <oauth@ietf.org <mailto: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 <mailto:torsten@lodderstedt.net>> wrote: >>> >>> > Am 15.11.2018 um 23:01 schrieb Brock Allen >>> <brockallen@gmail.com <mailto: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 <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] draft-parecki-oauth-browser-based-apps… Hannes Tschofenig
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Joseph Heenan
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Simon Moffatt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Tomek Stojecki
- [OAUTH-WG] draft-parecki-oauth-browser-based-apps… Daniel Fett
- [OAUTH-WG] draft-parecki-oauth-browser-based-apps… Daniel Fett
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Daniel Fett
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… n-sakimura
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Tomek Stojecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brian Campbell
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Vladimir Dzhuvinov
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Vladimir Dzhuvinov
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Hans Zandbelt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Jim Manico
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… George Fletcher
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Hans Zandbelt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brian Campbell
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Hannes Tschofenig
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… John Bradley
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Rob Otto
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Phil Hunt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Hans Zandbelt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… John Bradley
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brian Campbell
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki