Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Neil Madden <neil.madden@forgerock.com> Wed, 21 November 2018 09:09 UTC

Return-Path: <neil.madden@forgerock.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 0AEE3130EB4 for <oauth@ietfa.amsl.com>; Wed, 21 Nov 2018 01:09:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.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 PGeq6hvX_aRx for <oauth@ietfa.amsl.com>; Wed, 21 Nov 2018 01:09:09 -0800 (PST)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 597D1130EF6 for <oauth@ietf.org>; Wed, 21 Nov 2018 01:09:07 -0800 (PST)
Received: by mail-wr1-x42d.google.com with SMTP id b13so4814743wrx.6 for <oauth@ietf.org>; Wed, 21 Nov 2018 01:09:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Yr8FsjSJX0zv5+Fpcz0J5bNgsOVRdja95ZYFV/KhLp8=; b=g4S+8ysEjnkqsxc3or/yOxnNEhWIXeftTL6XS5PDudTURd3azoKVcMkwGMY5FfdkN3 r3sUeWZbtbCRVA5TWricKGf7j0EsP4/ZoZqgXH8TBcQiBexhA5e/DwI4WHp8IHzfwsNO oznzoD3l24WoboIip3G+Bb2Ve+VaA3vMqR8/Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Yr8FsjSJX0zv5+Fpcz0J5bNgsOVRdja95ZYFV/KhLp8=; b=Far48kWiFvLyG8rdnDWYaGc0r6JUYDvSNj/5YR60GTqBSrDQ8RSSsE0FDDbvJoT7cB Qe+0+qE5wn2gNp0MVGcA7xOwq587Lm7WNkwdfWp8VfK1UmNhC8vbko1haORazBXd+NGv KmC3gfXGuSobI5Z+FSeE4l5GsgIjNK5hfL/T1W5XNfo76z0EQByILdrqPt6zvt5RfhNK jMEttg+vEEuf3RDHsXJAFrUVFxHlHvLED/D02zukROmM2kSKgZN3B9lPZtl1mBqxRLfX zx15ciI6wM+qsFNQrPWl/tGPoZWhKSKMpJGa6HVDgKl1Nv0hP7HDafLZxwZKoTEUlplv GJJw==
X-Gm-Message-State: AA+aEWYBDqngqFVX7+w7GUC+OwjAcr6K/bKDSbibwna3arvhTEQT7Inr sHEvSM+AQNQ5VjW6X46B9nY6IA==
X-Google-Smtp-Source: AFSGD/X/x2CzCNYR9hctvzxhqGdh6hx3ZlXb2JFWHnpubDMao8uF0KEujaHM24ZcyvKnOjknY3fH5Q==
X-Received: by 2002:a05:6000:1189:: with SMTP id g9mr5263526wrx.221.1542791345581; Wed, 21 Nov 2018 01:09:05 -0800 (PST)
Received: from guest2s-mbp.lan (41.167.189.80.dyn.plus.net. [80.189.167.41]) by smtp.gmail.com with ESMTPSA id m80sm334506wmd.35.2018.11.21.01.09.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Nov 2018 01:09:04 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Neil Madden <neil.madden@forgerock.com>
In-Reply-To: <ccf62b34-5cd0-1473-ae7e-a7d166b28b80@yes.com>
Date: Wed, 21 Nov 2018 09:09:03 +0000
Cc: oauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3C8699BF-EE70-4299-91F2-87E8818E7464@forgerock.com>
References: <VI1PR0801MB211266BA6F6E06FFB3081425FAD80@VI1PR0801MB2112.eurprd08.prod.outlook.com> <BL0PR00MB029244CACC634E2D2E923B77F5D80@BL0PR00MB0292.namprd00.prod.outlook.com> <61A6D327-D4EE-4954-B57F-4FF42BB22E7E@lodderstedt.net> <3AA54AC6-BE0B-4535-AF1D-919236EF69B8@forgerock.com> <65005ad9-238e-9fe4-fb4b-ef54e93f84c3@yes.com> <92C3D667-E43E-4622-A688-689C216789BF@forgerock.com> <ccf62b34-5cd0-1473-ae7e-a7d166b28b80@yes.com>
To: Daniel Fett <danielf+oauth@yes.com>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/69OXW2zxuLb4pNFB_EqcLqaRHGs>
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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: Wed, 21 Nov 2018 09:09:11 -0000

On 21 Nov 2018, at 08:39, Daniel Fett <danielf+oauth@yes.com> wrote:
> 
> Am 21.11.18 um 09:34 schrieb Neil Madden:
>> On 21 Nov 2018, at 08:26, Daniel Fett <danielf+oauth@yes.com> wrote:
>> 
>>> Am 20.11.18 um 13:24 schrieb Neil Madden:
>>>> If we are discussing this in the context of client-side web apps/SPAs, then surely the threat model includes malicious 3rd party scripts - for which neither token binding nor mTLS constrained tokens are very effective as those scripts run in the same TLS context as the legitimate client?
>>>> 
>>> Please correct me if I'm wrong, but if a page/SPA/origin includes a malicious third party script, the third party script can access all data of that JavaScript. It can exfiltrate tokens and/or send requests on behalf of that page/SPA/origin (using the page/SPA/origin's TLS context, cookies, etc.). 
>>> 
>>> So I doubt that there is any better solution than token binding or mTLS.
>>> 
>>> If we assume that an SPA includes a malicious third party script, it is completely compromised.
>>> 
>> 
>> No - same origin policy prevents those things. TLS doesn’t have those protections though because it acts at the transport layer and SOP is an application-layer concept. 
> If a page from origin A includes a third-party script from origin B, that external script runs in origin A and has access to all cookies and the JavaScript context of the page.
> 
> The SPA from origin A would be compromised. That is why we need things such as Subresource Integrity.

I think we’re talking about different things. I am talking about scripts from places like ad servers that are usually included via an iframe to enforce the SOP and sandbox them from other scripts. If they get access to an access token - e.g. via document.referrer or a redirect or some other leak, then they still act within the same TLS context as the legitimate client.

— Neil