IETF Logo Mail Archive

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

David Waite <david@alkaline-solutions.com> Fri, 18 May 2018 17:42 UTC

Return-Path: <david@alkaline-solutions.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 D61F712DA25 for <oauth@ietfa.amsl.com>; Fri, 18 May 2018 10:42:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 uKR_IU8oToiL for <oauth@ietfa.amsl.com>; Fri, 18 May 2018 10:42:38 -0700 (PDT)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id A78E512DA06 for <oauth@ietf.org>; Fri, 18 May 2018 10:42:38 -0700 (PDT)
Received: from [IPv6:2601:282:202:b210:b1c1:9dc5:ed80:9403] (unknown [IPv6:2601:282:202:b210:b1c1:9dc5:ed80:9403]) by alkaline-solutions.com (Postfix) with ESMTPSA id C1F2131544; Fri, 18 May 2018 17:42:37 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DBDAF004-E118-4D0F-B1AF-17EF94248013"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: David Waite <david@alkaline-solutions.com>
X-Priority: 3
In-Reply-To: <5aff03b3.1c69fb81.a01df.2946@mx.google.com>
Date: Fri, 18 May 2018 11:42:36 -0600
Cc: Brock Allen <brockallen@gmail.com>, Hannes Tschofenig <hannes.tschofenig@arm.com>, "oauth@ietf.org" <oauth@ietf.org>
Message-Id: <0075D910-35DA-4B8B-A739-D57CF7A8765E@alkaline-solutions.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>
To: John Bradley <ve7jtb@ve7jtb.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/bGf-VoTLH9IgXYtfIoaGNmNMges>
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:42:42 -0000

I don’t believe code flow today with an equivalent token policy as you have with implicit causes any new security issues, and it does correct _some_ problems. The problem is that you immediately want to change token policy to get around hidden iframes and special parameters.

Once you start trying to alter token policy (such as adding refresh tokens), you start to have new security considerations because of the execution environment of javascript in the browser. Specifically token exfiltration from the browser origin, which can be mitigated via token binding or service workers.

You don’t need to exfiltrate a token for a third party to use a the associated access; they can inject behavior onto the page via XSS or a browser extension. This is not related to token lifetime policy, or the use of implicit vs code. This is the more immediate area where I see guidance being important - especially considering that token exfiltration becomes closer to a theoretical attack if the behavior of my app is controlled.

-DW

On May 18, 2018, at 10:47 AM, 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 <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>  
> From: Brock Allen <mailto:brockallen@gmail.com>
> Sent: Friday, May 18, 2018 6:36 PM
> To: John Bradley <mailto:ve7jtb@ve7jtb.com>; David Waite <mailto:david@alkaline-solutions.com>; Hannes Tschofenig <mailto:hannes.tschofenig@arm.com>
> Cc: oauth@ietf.org <mailto: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
>

v2.23.0 | Report a Bug | By Email