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

Daniel Fett <danielf+oauth@yes.com> Wed, 21 November 2018 08:26 UTC

Return-Path: <danielf+oauth@yes.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 D5623127332 for <oauth@ietfa.amsl.com>; Wed, 21 Nov 2018 00:26:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=yes.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 i0LQtDTI0zOM for <oauth@ietfa.amsl.com>; Wed, 21 Nov 2018 00:26:23 -0800 (PST)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 D862D124408 for <oauth@ietf.org>; Wed, 21 Nov 2018 00:26:22 -0800 (PST)
Received: by mail-ed1-x533.google.com with SMTP id f4so4140387edq.10 for <oauth@ietf.org>; Wed, 21 Nov 2018 00:26:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=ClW9X5OuEA5dzn4GjznNQysJ2xKaHCHF97odegZ/h8g=; b=tGuP1bHRSeh9X5Y5MjI4bYw1S0UDbAZ6kjnmB/v2RrS2y/ZMTOlLOfHjmT6K/E/xB8 ycjMx47d8s+6Oo+QaS/X4v6F4N+unNfWR7vl97WKDKEhZjebDQQBiPpPfUZHXdBtNUZn zEJ9Tz6SHycFjHwzvgr/c2ju73++ZLJbkYQZsNP+1NZg665PoZ2OWnDi/z0uAqH6VXfk 3r3aZqGmAxHMYDnkob2qVtvqkszPEMVaIKxx5cUVxY6dQ+N/W0EWD8dVlayOcsqBqf/g aSSi0DKEZyHtDTrGKeGKD6+xPyshAsxgij+aXxBrbPbEEMC/ZVNoJIq5jfNMbtKafHX0 MhNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ClW9X5OuEA5dzn4GjznNQysJ2xKaHCHF97odegZ/h8g=; b=iWSu33w6xbw1/gCSdA28E9zHkHLY38EYnuWWGUHxuECqYgH2zcQgbQic8Qpxhyi+gg vAHkZu/TzG4nppnMgN6eMkad8XmXlybr0u1hJwKUHr8MkK3uw3HyQUcBkUzik8ypphv6 uROA5UtTqI5nPwuwCAkHy/Jn+5IBbH4wGfkP1b96SAsKw9geKzSPhMnHTh747Ty08Yp3 swno7V+YkD1ZqzVR/pZ3F4qen8Isqm8bxt4OFa/7J+Wq+BvV7cTz0fglotAh8PG4ZacR FWRc/uxpBeTG/YPvLcskRor19569mvYp73Z/Xd0wdyyb/tLWz6IX4/CHJFwoArRRTdN4 Gubw==
X-Gm-Message-State: AA+aEWZ3pBSGqYCnjdC5U5IDUyrvM+LBj26r4XsOIY10e35I6HmhhVqJ 02gqHts1YTISbp1ECCE0ktA35r7JK10=
X-Google-Smtp-Source: AFSGD/Wl/j9VD8N4R76vNkijTZ7jCIeqTgdy+I1lEjVHl6pTc7M2VugvZxAv8odLc2ScVAgjhMgxZw==
X-Received: by 2002:a50:d48a:: with SMTP id s10-v6mr4884523edi.127.1542788780625; Wed, 21 Nov 2018 00:26:20 -0800 (PST)
Received: from [10.3.12.70] ([80.155.34.3]) by smtp.gmail.com with ESMTPSA id g13-v6sm6592637ejr.1.2018.11.21.00.26.19 for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Nov 2018 00:26:19 -0800 (PST)
To: oauth@ietf.org
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>
From: Daniel Fett <danielf+oauth@yes.com>
Message-ID: <65005ad9-238e-9fe4-fb4b-ef54e93f84c3@yes.com>
Date: Wed, 21 Nov 2018 09:26:19 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <3AA54AC6-BE0B-4535-AF1D-919236EF69B8@forgerock.com>
Content-Type: multipart/alternative; boundary="------------6E0C84728C14BA5D8ECD270B"
Content-Language: de-DE
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/F9h6eWX_D0ovarFriWcAnd01LWU>
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 08:26:25 -0000

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.

-Daniel