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

Jim Manico <jim@manicode.com> Fri, 18 May 2018 20:12 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 9276012E03C for <oauth@ietfa.amsl.com>; Fri, 18 May 2018 13:12:02 -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 Hk98TBlzKIWg for <oauth@ietfa.amsl.com>; Fri, 18 May 2018 13:11:59 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 EC37012DB72 for <oauth@ietf.org>; Fri, 18 May 2018 13:11:58 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id q7-v6so2777310ywd.9 for <oauth@ietf.org>; Fri, 18 May 2018 13:11:58 -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=aJPtxq2XvcuLh1NyhR0D7Dyh3UcCiH96SrH9z6uqJcI=; b=bPbndytPiz69S+3M3rJnpzwO8MxEqCf7jrnUHKktG1cL7xWMH2+CZ7r4/w4hhVrVJl toB6HzvvI8fnfIMf+16v6E07lXaEl0U2GzG6mM7AHkJKt50MkM3stYoHSgg5f0vww0o3 0XymQdUAo+dDnclBbiRnRHrAKCTO6abm8pu7esTOTKDMHuy4WXIm2azSKFJxVwfcw+7m muvVE/omf2UnzLmhTkZ0XbJfqEd9gPsqrJlmlEZK+sOz/sqgNBjrmLKSqVM5BvGOF7uW 9H2QZZfNwuuE8S1K4WZu8et2QrJWXtIb3K9wNQOTQHBSi7Joh6kU3Lf1WFYmU8yQyNoo bgKg==
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=aJPtxq2XvcuLh1NyhR0D7Dyh3UcCiH96SrH9z6uqJcI=; b=A6S+d2yX92oKWsJG/4o0sPMYNnr4dxEBMpTa0J2FMgmXjOHV6J56NwdnUkGjTSSJ4e uvNxbQR3p+lVZ6UKMT5Vd2QbR8tYA7iV3PPL3LrtQvdwrGxPK6x5lHKENljI/oJzKND/ xTowJhR9ae+L8P7lcqqxs6uOCSDqgmlZGthj8iBq4Qz3em7fwlSTCLkLMvuOjQVuV+p9 u07Orho5V1uoKQ0pa9f72AK4+pycOJYMN1dqh2XtbjwOGEkkqRCarpMqBMRzVX/V1zaX 2c+YYetW7dVMT1xSqcoECh87HuYcQnm8L5TeC4Z7+o3f8inydUKBixMJJNamj0wff0Kl l4Lw==
X-Gm-Message-State: ALKqPwca9igH4D/swhvL2dMllWZkvGjqRxPfLjXF8mpXpZELfbMJvLsx YP0rjvybtjE6TDLqvlxI/e9UlA==
X-Google-Smtp-Source: AB8JxZpwW00IWLfCGcjsBGXIlwR49xECunQ4CKI4JGVuExf5NOqawrl5sB/MtFNkbqIuLBPTpMeLHQ==
X-Received: by 2002:a0d:e208:: with SMTP id l8-v6mr5678962ywe.193.1526674317742; Fri, 18 May 2018 13:11:57 -0700 (PDT)
Received: from [10.242.17.219] (mobile-166-172-59-55.mycingular.net. [166.172.59.55]) by smtp.gmail.com with ESMTPSA id z11-v6sm3405883ywb.3.2018.05.18.13.11.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 13:11:56 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-9760D730-2A9C-496A-ACB0-4AD7B67F0924"
Mime-Version: 1.0 (1.0)
From: Jim Manico <jim@manicode.com>
X-Mailer: iPhone Mail (15E302)
In-Reply-To: <9f849caf-1f78-48b2-8cc9-9e0ad0299ce2@Canary>
Date: Fri, 18 May 2018 16:11:55 -0400
Cc: John Bradley <ve7jtb@ve7jtb.com>, "oauth@ietf.org" <oauth@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <CB70852F-BECA-49FB-8E19-E6C168220055@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> <82F844B0-63A5-419D-8A81-B7523CA4CB87@manicode.com> <b9b91d09-c10c-4cba-9529-1da0e99de4e2@Canary> <5aff116b.1c69fb81.e47d3.d1f0@mx.google.com> <9f849caf-1f78-48b2-8cc9-9e0ad0299ce2@Canary>
To: Neil Madden <neil.madden@forgerock.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/833XouhsIwARvPfVRKjSXZE3HiE>
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 20:12:03 -0000

What you call pessimism I call stating fact! 😎 

This has nothing to do with SPA apps. Like Neil says any XSS in play and token binding, HTTPOnly and similar do nothing to protect you. This is any web app. 

And XSS defense in a complex app is rough. Take the time to study it! I’m happy to present on XSS defense in-depth to the Oath standard body community if you wish. It’s a lot more difficult to get right than most think.

Once you have XSS, dang. Might as well just stick unsigned AT’s in URL’s.

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

> On May 18, 2018, at 2:51 PM, Neil Madden <neil.madden@forgerock.com> wrote:
> 
> Ha! Well it was Jim Manico’s pessimism about http-only cookies that started it! :-)
> 
> I agree with Jim about http-only, and I agree with you that token binding has lots of other good advantages. But pretty much all security is lost if XSS is a possibility. Even storing secrets on the server does not help much as if I can forge requests from the same origin then I can probably trick the server into performing actions on my behalf too. Preventing/mitigating XSS is crucial (CSP is a big help), but that is not specific to OAuth. 
> 
> — Neil
> 
> On Friday, May 18, 2018 at 6:46 pm, John Bradley <ve7jtb@ve7jtb.com> wrote:
> You cant extract a token bound cookie or AT and use it in a different user agent.
> 
>  
> 
> You could still force the user agent to use a token bound cookie itself. 
> 
>  
> 
> For the AT and refresh they are not cookies so they need to sent by the JS so may be harder to trigger?
> 
>  
> 
> I thought I was the pessimistic one😊
> 
>  
> 
> SPA may turn out to be impossible to completely secure.  However that wont stop people from creating them.
> 
>  
> 
> We can try to put together the best advice, and limit the damage.
> 
>  
> 
> John B.
> 
>  
> 
> Sent from Mail for Windows 10
> 
>  
> 
> From: Neil Madden
> Sent: Friday, May 18, 2018 7:38 PM
> To: John Bradley; Jim Manico
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
> 
>  
> 
> I might be missing something here, but aren’t bound tokens exactly as vulnerable to the XSS attacks you describe as http-only cookies are? 
> 
>  
> 
> — Neil
> 
>  
> 
> On Friday, May 18, 2018 at 5:43 pm, Jim Manico <jim@manicode.com> wrote:
> 
> A few notes:
> 
> > The session cookie should also be flagged as http only to protect it.  
> 
>  
> 
> This provides no real protection. If I get XSS into your site I don’t need to steal the cookie. I can just force requests that will automatically send it (client side or stored request forgery). So while it’s a standard suggestion, it helps little. 
> 
>  
> 
> > Having a refresh token in local storrage may introduce new security issues unless it is token bound.  
> 
>  
> 
> Token binding is not live yet, right? If you need to store a token in a browser please note there is no safe place to store it. LocalStorage can be harvested by XSS and even the strongest cookies can be replayed as discussed above. I can’t wait for browser based token binding! But it will likely take years for this to be avail in the majority of browsers.
> 
>  
> 
> > Understanding the security issues of the code flow in the browser is important, before any new recommendation.  
> 
>  
> 
> Well said. It looks to be the only secure workflow for browser based apps. Love it how passwords are kept away from RP’s and high powered tokens are not stored in the browser.
> 
>  
> 
> Aloha,
> 
> --
> 
> Jim Manico
> 
> @Manicode
> 
> Secure Coding Education
> 
> +1 (808) 652-3805
> 
> 
> On May 18, 2018, at 12:27 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
> 
> _______________________________________________ 
> OAuth mailing list 
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth
>