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

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

MIME-Version: 1.0
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
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
Precedence: list

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
>
>
>
>
>

[OAUTH-WG] Recommendations for browser-based apps Aaron Parecki
Re: [OAUTH-WG] Recommendations for browser-based … ve7jtb
Re: [OAUTH-WG] Recommendations for browser-based … Aaron Parecki