Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

Jim Manico <jim@manicode.com> Fri, 18 May 2018 17:18 UTC

Return-Path: <jim@manicode.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 4157512D86B for <oauth@ietfa.amsl.com>; Fri, 18 May 2018 10:18:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Level:
X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-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 kRb0gJEZOpKx for <oauth@ietfa.amsl.com>; Fri, 18 May 2018 10:18:15 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 41825126BF3 for <oauth@ietf.org>; Fri, 18 May 2018 10:18:15 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id z4-v6so7046704iof.5 for <oauth@ietf.org>; Fri, 18 May 2018 10:18:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K01t0W9dDeaVEhbHVXYJoerIQaCGuYXgL9n65ofTLPI=; b=fG3dQ0ky66TI/eS75mSMV7PNqTSNITlVOUKJHms2g404DRhON4sVLRpqtgXwh+kVlJ jzwpQpMU62j5ZwetEHB6X1RpD0z7pUdm2SLUJ6ldK0LggNbiNxIxOv/p6lIdx3HudgYA iH+T6SNazRKtRBd+BeMS+Rkl+jY2y0N6DMlomXc8VoJP6JqFbPckckSe5PlHrmdFGf18 TV45HrHzpj3r6XHYWFGpF88xKhNAPDXz8oM/ZlwuDTgE/uZjCKVjfXgKq53pI6kfO6uE 3JMA2CeMv8IyYnlDLn7Jt4vNHDTlqnExXnobUk1gS9VD0eozVIQon9Q4SzgdKPYTahfc wzjg==
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=K01t0W9dDeaVEhbHVXYJoerIQaCGuYXgL9n65ofTLPI=; b=Er+/FICIBf+Bc1xn6Apx7aB9jB66xieCSIIQzScptNxwLqKyIf23u3m4ZK1E0rVj1h Yum7xrhQzKarEL+GXkR2q3sAPHhHQFzgl92uwo86sDF/Cr7T/f+sb7DACg7+f4jJr6Q2 aReRY3BVXn4lZH80IKUCKSvCA0L7a43CJ8f0SOeckBUDSiqxVwxyfdMvMPG1+0HGO/ep h1MB/WB2rHKX3HazABqXj4kM4MQ5zWQBpvU6Gce4k9qU5EFs0F7E95g2Rrr3gfx+fyN0 3Z/gu8RyXNJCBm6TGfd/0oe4hobe9wFxQYw11EAxSxZiyZ4UMTEdUMhn0lsbfBHiqk8z hxGA==
X-Gm-Message-State: ALKqPwfKK2Q6lg/k0wb3lsvZPt00UgWoEq1s//la1c3Z5lNK8XnBhvsh Rw19mozCVB1JkIUWvZXa0gpU9Q==
X-Google-Smtp-Source: AB8JxZofGzm8gpxpn9SHuqfuDkD3UmM+BbSLJohNHcG/zT6OYyPZv+07psMrmyHUjAKh2hzH9Voy8A==
X-Received: by 2002:a6b:f00d:: with SMTP id w13-v6mr11091781ioc.296.1526663894521; Fri, 18 May 2018 10:18:14 -0700 (PDT)
Received: from [10.102.248.12] (mobile-166-176-251-17.mycingular.net. [166.176.251.17]) by smtp.gmail.com with ESMTPSA id v62-v6sm4801662itd.16.2018.05.18.10.18.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 10:18:13 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-5B1D551A-1BC8-4263-BA55-450F53EED19A
Mime-Version: 1.0 (1.0)
From: Jim Manico <jim@manicode.com>
X-Mailer: iPhone Mail (15E302)
In-Reply-To: <c56c669d-24f3-4099-83b2-51942a2bce61@getmailbird.com>
Date: Fri, 18 May 2018 13:18:12 -0400
Cc: John Bradley <ve7jtb@ve7jtb.com>, David Waite <david@alkaline-solutions.com>, Hannes Tschofenig <hannes.tschofenig@arm.com>, oauth@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <A1067294-A527-461C-814F-3BEE46317C97@manicode.com>
References: <ab42d84a-5f08-4600-aa36-92e73944cf6c@getmailbird.com> <VI1PR0801MB2112A6F8B47939F8748DEA43FA910@VI1PR0801MB2112.eurprd08.prod.outlook.com> <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com> <, 895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com> <MWHPR19MB1085FC4579E0A656BB78A8ABFA900@MWHPR19MB1085.namprd19.prod.outlook.com> <22977d8a-ead8-49fe-83c0-46c5c594ac40@getmailbird.com> <5aff03b3.1c69fb81.a01df.2946@mx.google.com> <c56c669d-24f3-4099-83b2-51942a2bce61@getmailbird.com>
To: Brock Allen <brockallen@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/x1wRFXZRkz2d_lrFZ3TGblTHs_M>
Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 18 May 2018 17:18:18 -0000

> However moving the token used for refresh from being a HTTP only cookie to a refresh token available in the DOM makes me uncomfortable without having sufficient mitigations against XSS.

My conjecture is that it does not matter >>at all<< where you store tokens in relation to XSS. There is no secure place to store data in a browser in ways that cannot be abused by XSS. One XSS is complete compromise of the client. I’m happy to discuss in detail with POC’s offline if you like. HTTPOnly cookies do absolutely nothing to stop an attacker from leveraging XSS to forge requests through a victims browser, a much more common red team attack than trying to steal a cookie.

And XSS resistant apps are illusive. For example .NET is missing core controls around XSS defense like a well maintained HTML sanitizer for HTML input. 

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On May 18, 2018, at 12:53 PM, Brock Allen <brockallen@gmail.com>; wrote:
> 
> Fair enough, and I'm happy that this discussion has started. 
> 
> For now, IMO, CSP is a big help in protecting these types of apps. Token binding will of course help too, once it's available/practical.
> 
> -Brock
> 
>> On 5/18/2018 12:47:49 PM, John Bradley <ve7jtb@ve7jtb.com>; wrote:
>> 
>> There are lots of issues with the current implicit flow around fragment encoding as well.
>> 
>>  
>> 
>> However moving the token used for refresh from being a HTTP only cookie to a refresh token available in the DOM makes me uncomfortable without having sufficient mitigations against XSS.
>> 
>>  
>> 
>> The current flow is vulnerable to  XSS for the AT, however if that is short lived it restricts the damage.
>> 
>>  
>> 
>> The better solution is token binding the AT and perhaps a RT. 
>> 
>>  
>> 
>> We need to start talking about it.  There are issues around potentially using service workers etc as well.
>> 
>>  
>> 
>> So we should start but I am not sure of what the correct answer is yet.
>> 
>>  
>> 
>> John B.
>> 
>>  
>> 
>> Sent from Mail for Windows 10
>> 
>>  
>> 
>> From: Brock Allen
>> Sent: Friday, May 18, 2018 6:36 PM
>> To: John Bradley; David Waite; Hannes Tschofenig
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
>> 
>>  
>> 
>> It sounds to me as if you're hesitant to recommend code flow (at least for now) then for browser-based JS apps.
>> 
>>  
>> 
>> -Brock
>> 
>>  
>> 
>> On 5/18/2018 12:27:48 PM, John Bradley <ve7jtb@ve7jtb.com>; wrote:
>> 
>> Yes that was the original intent to have the AT be short lived and refresh the AT via the authorization endpoint based on the session cookie. 
>> 
>> The session cookie should also be flagged as http only to protect it. 
>> 
>> Having a refresh token in local storrage may introduce new security issues unless it is token bound. 
>> 
>> Understanding the security issues of the code flow in the browser is important, before any new recommendation. 
>> 
>> John B.
>> 
>> From: Brock Allen
>> 
>> Sent: Friday, May 18, 2:46 PM
>> 
>> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
>> 
>> To: David Waite, Hannes Tschofenig
>> 
>> Cc: oauth@ietf.org
>> 
>> 
>> One thing I maybe should have listed in the pros/cons in my original email is session management and token lifetime considerations, keeping in mind the original intent of the implicit flow.
>> 
>> What I mean is that with implicit grant type, the client's ability to get new access tokens is limited to the user's session at the AS/OP. Obviously other flows make more sense to obtain longer lived access (via refresh tokens), but I don't know about a browser-based JS app. In a sense there's a bit of protection for the end user built into that design by virtue of being tied to the user's cookie at the AS/OP.
>> 
>> Just throwing that out as an additional discussion point.
>> 
>> -Brock
>> 
>> On 5/18/2018 6:04:47 AM, David Waite <david@alkaline-solutions.com>; wrote:
>> 
>> I have written some guidance already (in non-RFC format) on preferring code for single page apps, and other security practices (CORS, CSP). From the AS point of view, it aligns well with the native apps BCP. There are benefits of thinking about native and SPA apps just as ‘public clients’ from a policy/properties point of view. It also greatly simplifies OAuth/OIDC support on both the AS administrator and client developer side when converting web properties into native apps using technologies like Electron or Cordova.
>> 
>> For the later requirements in the list around token policy, I am not sure these are requirements for single page apps per se. I don’t believe the need for a policy using short-lived refresh tokens, revoking at signout, or use of the revocation endpoint are different from browser and native applications. Rather they seem to be a function of usage patterns that an AS may need to support, and we happen to sometimes associate those usage patterns with typical usage of native apps vs of browser apps. For example, browser login on a borrowed device can easily leak over to being app authorization - the authentication/authorization are web-based processes to achieve SSO.
>> 
>> I have been working on some guidance here around token lifetimes and policies, but I don’t know whether that brings in too much AS/OP business logic (and, likely implied product/deployment features) to be industry practices.
>> 
>> -DW
>> 
>> On May 17, 2018, at 10:23 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com>; wrote:
>> 
>> Hi Brock,
>> 
>>  
>> 
>> there have been several attempts to start writing some guidance but so far we haven’t gotten too far..
>> 
>> IMHO it would be great to have a document.
>> 
>>  
>> 
>> Ciao
>> 
>> Hannes
>> 
>>  
>> 
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brock Allen
>> 
>> Sent: 17 May 2018 14:57
>> 
>> To: oauth@ietf.org
>> 
>> Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
>> 
>>  
>> 
>> Much like updated guidance was provided with the "OAuth2 for native apps" RFC, should there be one for "browser-based client-side JS apps"? I ask because google is actively discouraging the use of implicit flow:
>> 
>>  
>> 
>> https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290
>> 
>>  
>> 
>> From what I can tell, the complaints with implicit are:
>> 
>> * access token in URL
>> 
>> * access token in browser history
>> 
>> * iframe complexity when using prompt=none to "refresh" access tokens
>> 
>>  
>> 
>> But this requires:
>> 
>> * AS/OP to support PKCE
>> 
>> * AS/OP to support CORS 
>> 
>> * user-agent must support CORS
>> 
>> * AS/OP to maintain short-lived refresh tokens 
>> 
>> * AS/OP must aggressively revoke refresh tokens at user signout (which is not something OAuth2 "knows" about)
>> 
>> * if the above point can't work, then client must proactively use revocation endpoint if/when user triggers logout
>> 
>>  
>> 
>> Any use in discussing this?
>> 
>>  
>> 
>> -Brock
>> 
>>  
>> 
>> 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
>> 
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> 
>> 
>>  
>> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth