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

Daniel Fett <danielf+oauth@yes.com> Wed, 21 November 2018 10:06 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 D47381298C5 for <oauth@ietfa.amsl.com>; Wed, 21 Nov 2018 02:06:54 -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 VkW6XSGtAqvO for <oauth@ietfa.amsl.com>; Wed, 21 Nov 2018 02:06:53 -0800 (PST)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 209EE128CFD for <oauth@ietf.org>; Wed, 21 Nov 2018 02:06:53 -0800 (PST)
Received: by mail-ed1-x530.google.com with SMTP id y56so4369164edd.11 for <oauth@ietf.org>; Wed, 21 Nov 2018 02:06:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=xnAF523jTNVQs01VtbVRu6eHJmYrNM5Q85T/wN+cw0E=; b=B9O/lmyZeqkdGzUO9t1vSd5tvGFCJBAd6H0GdK24/H9z0iFoeUajZH1kVe1Hq5LahQ 7hXgjJXO59nHQHZ0WRWHK+6SCX1wmkfBMXLVEv8ViTALndVkyVNZ5QSpSqcncBXczIby 9Ri40+UqXAOljSqrni1PEw5hfYkkry13j8pYdSZI11sEKwESmoynYClj+e1pXkkNWAVt t5y7F7sRQUkc93srmILKpSuiBGL7nd8xzVpjgqyNor6AL34nQD+ufdsK/kaJlxR/cJx2 pPGtWvTjDhKIhIPmBTrzHBQnhGtY2Ivo2cnnAm2K27nNjuuCcLE7RN8W5zzruVQ6Hr1L XHmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=xnAF523jTNVQs01VtbVRu6eHJmYrNM5Q85T/wN+cw0E=; b=A0foFgGnyGiSUSQOR+Y2kVRx6yeE54+o9mgrnc0gNpV0n8M24jiehqwxm17CkADMZM HYUZFzE6RRXA6AToC6MawrnJOUqOBmA07CIfb5Md1Enod91+MvN1uClUlxyRUj/fhJ2g u68l7EQhdyPU67+AQQexDBhJ0ZtFljYQAHu56v/R/CNG2Dqx5QG03iEAztedKYt/wCUe 1tuM7gkMyZdypXuW161qtkgDbIP0usw6bAcrnuZVdel9U3v1LNRp5QwBndtlq/c//HNq ZQm85NlEvbr2zHCfWgs1ssv1Kl9BI25E+SFyzwdk0ScjkS3o3i6R6pB6HpyWNgvrQnqE f8hg==
X-Gm-Message-State: AGRZ1gKBv6UpHegZ8JrVIwF+mH130/f694SbOmlQkB7c8NYNDEqt11Tn eXPe8EHiLvsC3JDZfDom94dMXhSJYCw=
X-Google-Smtp-Source: AJdET5eLGSlnEtNcjzp4hNQhn5a33EMQUdGpCArLRESyzTXPR397gYsRDLuQYvqFdr7qYQDMmppt2g==
X-Received: by 2002:a17:906:4003:: with SMTP id v3-v6mr4624602ejj.240.1542794811084; Wed, 21 Nov 2018 02:06:51 -0800 (PST)
Received: from [10.3.12.70] ([80.155.34.3]) by smtp.gmail.com with ESMTPSA id k32sm5393898edb.42.2018.11.21.02.06.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Nov 2018 02:06:50 -0800 (PST)
To: Neil Madden <neil.madden@forgerock.com>
Cc: 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> <65005ad9-238e-9fe4-fb4b-ef54e93f84c3@yes.com> <92C3D667-E43E-4622-A688-689C216789BF@forgerock.com> <ccf62b34-5cd0-1473-ae7e-a7d166b28b80@yes.com> <3C8699BF-EE70-4299-91F2-87E8818E7464@forgerock.com> <83034de5-cde8-8cd9-ff11-7ce22b61fee6@yes.com> <70557E9F-8A8B-4BEB-80CC-07EFD74FFBF0@forgerock.com>
From: Daniel Fett <danielf+oauth@yes.com>
Message-ID: <13ca2226-ce91-40f7-c040-dde3f7b3f611@yes.com>
Date: Wed, 21 Nov 2018 11:06:49 +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: <70557E9F-8A8B-4BEB-80CC-07EFD74FFBF0@forgerock.com>
Content-Type: multipart/alternative; boundary="------------7672D01F2067ABA885AF7A10"
Content-Language: de-DE
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/kQR3K_7z6dGMUCeSv9e9itfwMDc>
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 10:06:55 -0000

Am 21.11.18 um 11:01 schrieb Neil Madden:
>> On 21 Nov 2018, at 09:25, Daniel Fett <danielf+oauth@yes.com> wrote:
>>
>> Am 21.11.18 um 10:09 schrieb Neil Madden:
>>>> 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.
>> Thanks for the clarification! I see that you highlight an important point there.
>>
>> The protection that would be required essentially boils down to something similar to a CSRF protection for the resource server.
>>
>> Luckily, CORS covers this: You can't set the Authorization header cross-origin unless the appropriate CORS headers are set. So while the third party origin would be able to send a request through the browser using the TLS context, it would not be able to attach the access token. (Unless, of course, that third party origin is whitelisted, or if the bearer token is sent in a different way, e.g., as a URL parameter.)
> Right. But two points here:
>
> Firstly, this assumes the access token is actually passed in an Authorization header and not just sent in a URL parameter or a CORS-safe form POST body (e.g. application/x-www-form-urlencoded). This should probably be its own security best practice recommendation, but I haven’t seen it anywhere. I think most REST APIs already do this following RFC 6750, but we should spell out that it has security benefits.

Exactly what I thought. I will prepare a proposal for the security BCP.

-Daniel