Re: [OAUTH-WG] Recommendations for browser-based apps

Aaron Parecki <aaron@parecki.com> Thu, 26 January 2017 00:43 UTC

Return-Path: <aaron@parecki.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 A4C6112943F for <oauth@ietfa.amsl.com>; Wed, 25 Jan 2017 16:43:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-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 MVBY7pAi8mFj for <oauth@ietfa.amsl.com>; Wed, 25 Jan 2017 16:43:28 -0800 (PST)
Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 BB0CF12943D for <oauth@ietf.org>; Wed, 25 Jan 2017 16:43:27 -0800 (PST)
Received: by mail-ua0-x229.google.com with SMTP id 35so172104093uak.1 for <oauth@ietf.org>; Wed, 25 Jan 2017 16:43:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=02Z8rH6/K82BfbjiBwPlBZnSnMzTgMY4MFkGLzxuHRU=; b=xvaKankpIdNGmejuFSyNf947Yj60m+lg+j2V7MrlGzKLbnrMxViiHN0U/WSZeRiCY0 JjzIJa4pyW5wGQMqYoQuvYBQP+fLu3UFKJjODuuz1ve2bcejHJvs2Li0EZU4r8Xm6wGL /JDqt53yosuG4947smkVeYBR9suFjWoKjAKVjnYLcpA2sMa/yUoSu6lJOkdxKTfBSULD Sr+K85x0SMtpTED9Z7Z9lrXbiCBNnZKjkn2qEoHQftsqe4WB+5HqNHnmG/YZRwLhQpx4 ksPTLNIrWUvjKEW9f5Bc68k9k8TkL7m7Qn3fGiSftly7JSzi0tmspwzR2+Nqoc8TO+oN fE0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=02Z8rH6/K82BfbjiBwPlBZnSnMzTgMY4MFkGLzxuHRU=; b=XTrTmq41FukamrykMxdvmTdg48CmOX+Dfc4HmgCQwgjpU6jqEt6FBoQbMofXMOf0/9 turGxq1uA2XoX5meE4379jZhmDgqA4PoZeQC/FZId35SrnDYQ30nhUDKUqTwCNQq2Yyx ILQ8dcMRjje4aCnxOtXJLkSMKyeqSCjaR3+aXfbgmbkgiO+6LXtc0Ij2Cib3aMmk6ba/ vU5NHVRvxhDQEtsVEGbcC9QKljgYiGT7IeotdfsLEzzWehy8y4F+OdX37qyTrYFSyNUb r/ScS5ALPDHYoGqwRAjGKVteTn1tnOJJwNdeqlU/I+CGObAqHQ/u+CoxDPcL/z4kXJpw PVAg==
X-Gm-Message-State: AIkVDXKSCOALFjcdmWbD2bY6JCEernGOkzkZL0xfez4dXOPLIQZd3OTUOsacuwEbiFXq7g==
X-Received: by 10.176.16.73 with SMTP id g9mr90611uab.92.1485391406569; Wed, 25 Jan 2017 16:43:26 -0800 (PST)
Received: from mail-vk0-f46.google.com (mail-vk0-f46.google.com. [209.85.213.46]) by smtp.gmail.com with ESMTPSA id i8sm9790525uad.3.2017.01.25.16.43.25 for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 16:43:26 -0800 (PST)
Received: by mail-vk0-f46.google.com with SMTP id x75so145446528vke.2 for <oauth@ietf.org>; Wed, 25 Jan 2017 16:43:25 -0800 (PST)
X-Received: by 10.31.63.88 with SMTP id m85mr58169vka.158.1485391405736; Wed, 25 Jan 2017 16:43:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.36.132 with HTTP; Wed, 25 Jan 2017 16:43:25 -0800 (PST)
In-Reply-To: <588941a1.1121620a.1d24d.86e2@mx.google.com>
References: <CAGBSGjqz1nwAWgwauqxt8ZRVTnDCu+L_p2=6v1zgkecsgso8TQ@mail.gmail.com> <588941a1.1121620a.1d24d.86e2@mx.google.com>
From: Aaron Parecki <aaron@parecki.com>
Date: Wed, 25 Jan 2017 16:43:25 -0800
X-Gmail-Original-Message-ID: <CAGBSGjqMHqpZvZ-zedDjPGTnj5jcd1cdH5W8CAAyu5SaUHgZsA@mail.gmail.com>
Message-ID: <CAGBSGjqMHqpZvZ-zedDjPGTnj5jcd1cdH5W8CAAyu5SaUHgZsA@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary=001a114dccfe176f700546f4a3a4
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Rgoa4hvjNRZtWYaz3YQ1sUf-I-Y>
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Recommendations for browser-based apps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 26 Jan 2017 00:43:29 -0000

Yeah, I guess the terminology now is "single-page apps."

These apps don’t by definition need offline access as they go away when the
> user is not present.


I'm sure there are plenty of cases of people creating SPAs that store the
access token in a cookie or Local Storage and resume that session when the
user loads the browser again. Not that it's necessarily a good idea, but
I'm sure it's been done.

It seems like avoiding the concerns of the Implicit flow described in
the threat
model <https://tools.ietf.org/html/rfc6819#section-4.4.2> by using the
authorization code flow is a good idea anyway, especially as these
single-page apps start to look more and more like native apps.

Basically I'm struggling to think of a reason to recommend using the
Implicit flow when it's not much harder to use the authorization code flow
in the first place.

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>


On Wed, Jan 25, 2017 at 4:24 PM, <ve7jtb@ve7jtb.com> wrote:

> It depends on what you mean by browser based apps.
>
>
>
> In general for single page apps that are java script executing in the
> browser dom, the recommendation would be implicit flow.
>
>
>
> These apps don’t by definition need offline access as they go away when
> the user is not present.
>
>
>
> We have talked about developing guidance for single page apps, but don’t
> have anything yet.
>
>
>
> I think it needs to be thought through again now that new things like
> service workers are available, and we will eventually get token binding in
> the browser (hint it is on in IE and Edge on windows 10 preview and in
> Chrome behind a feature flag now)
>
>
>
> You could use the PKCE appAuth type flow in a SPA app if you have the
> correct CORS setup.
>
> I however cant at this point say that you are getting improved security
> for the extra work in that environment.
>
>
>
> John B.
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Aaron Parecki <aaron@parecki.com>
> *Sent: *January 25, 2017 3:12 PM
> *To: *OAuth WG <oauth@ietf.org>
> *Subject: *[OAUTH-WG] Recommendations for browser-based apps
>
>
>
> Thanks to the new "OAuth 2.0 for Native Apps" and PKCE documents, we have
> a solid recommendation for how to do OAuth 2.0 for native apps.
>
>
>
> Given that PKCE is intended for "public clients" and not specifically
> native apps, I'm wondering where that leaves browser-based apps. The core
> spec still says that the implicit grant is recommended for browser-based
> apps, but it's looking like the recommendation is to use the authorization
> code flow + PKCE with no secret for browser-based apps.
>
>
>
> Am I correct in thinking that the general recommendation would be to use
> the authorization code flow with no secret, and even better to use PKCE for
> browser-based apps?
>
>
> ----
>
> Aaron Parecki
>
> aaronparecki.com
>
>
>
>
>