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

From: Stefan Büringer <[email-masked]>
Date: Tue, 19 Sep 2017 15:27:02 +0200

Hi,

there were some discussions in January regarding recommendations for
browser-based apps (
https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html).

I'd just like to ask if the Authorization Code Flow with PKCE is a valid
option for Single-Page-Applications (in our case Angular), because Implicit
Flow cannot be used in our scenario.

Authorization Code Flow with PKCE eliminates the necessity for client
secrets, but our concern is that exposing the refresh token to the SPA
might be a security risk, compared to the Implicit Flow were no refresh
token is exposed.

What's your take on this?

Kind regards,
Stefan Büringer

P.S. I couldn't find that much on the internet regarding Authorization Code
Flow with PKCE in SPAs, if you have some recommendations for good blog
posts I would be grateful.

---

From: Bill Burke <[email-masked]>
Date: Tue, 19 Sep 2017 17:33:52 -0400

I'd be curious to the response to this too.

Seems to me that refresh token has the same possible security risks in
an Angular app as an access token, except the refresh token is valid
longer....Still, if you did the implicit flow, you'd have to have
longer access token timeouts as it would be really annoying for the
user to have to login again and again in a long session with your
Angular app.

We have a javascript adapter that does Authz Code Flow with PKCE for
our Angular app.  It also does CORS checks on the code to token XHR
request just in case on the IDP side.

On Tue, Sep 19, 2017 at 9:27 AM, Stefan Büringer <[email-masked]> wrote:
> browser-based apps
> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html).
>
> secrets, but our concern is that exposing the refresh token to the SPA might
> be a security risk, compared to the Implicit Flow were no refresh token is
> exposed.
>
> Flow with PKCE in SPAs, if you have some recommendations for good blog posts
> I would be grateful.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Bill Burke
Red Hat

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Tue, 19 Sep 2017 14:47:31 -0700

Except a refresh token is not purely bearer. The client is required to authenticate to use it. 

Phil

> On Sep 19, 2017, at 2:33 PM, Bill Burke <[email-masked]> wrote:
>

---

From: Jim Manico <[email-masked]>
Date: Wed, 20 Sep 2017 05:54:45 +0800

One of the reasons I see so many security folk discouraging implicit in web applications (like your Angular scenario) is because even though refresh tokens and similar require authentication, how do you store that info securely in a browser? One XSS and it's http://m.youtube.com/watch?v=dsx2vdn7gpY

- Jim

> On Sep 20, 2017, at 5:47 AM, Phil Hunt (IDM) <[email-masked]> wrote:
>

---

From: Adam Lewis <[email-masked]>
Date: Tue, 19 Sep 2017 17:02:51 -0500

Only for confidential clients.  No authentication is required for public
clients.

On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) <[email-masked]>
wrote:

> might

---

From: John Bradley <[email-masked]>
Date: Tue, 19 Sep 2017 19:32:42 -0300

Right,  Refresh token is bearer for native apps, that is why we came up with PKCE to protect code.

For Angular the code flow with PKCE is probably better than the token response type.   

However with bearer tokens it is still riskier than code with a confidential client so the AS should take that into account and not allow refresh tokens to live forever.

One future way to protect refresh tokens and perhaps Access tokens is to use token binding to bind the tokens to the user agent.   You could do that now for refresh tokens in Edge (Chrome has TB off by default still).  

I think more work needs to be done to come up with a best practice for SPA.

John B.

> On Sep 19, 2017, at 7:02 PM, Adam Lewis <[email-masked]> wrote:
> 
> Only for confidential clients.  No authentication is required for public clients.
> 
> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
> > On Sep 19, 2017, at 2:33 PM, Bill Burke <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >> On Tue, Sep 19, 2017 at 9:27 AM, Stefan Büringer <[email-masked] <mailto:[email-masked]>> wrote:
> >> Hi,
> >>
> >> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html <https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html>).
> >>
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >>
> >
> >
> >
> > --
> > Bill Burke
> > Red Hat
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: nov matake <[email-masked]>
Date: Wed, 20 Sep 2017 08:48:59 +0900

Why not using http-only cookies instead of refresh tokens?
If the app can interact with AuthZ server through a hidden iframe with prompt=none param, you shouldn’t need refresh tokens.

If your SAP is running on a different domain with the backend server, Safari’s Intelligent Tracking Prevention will break the hidden iframe way though.

> On Sep 20, 2017, at 7:32, John Bradley <[email-masked]> wrote:
> 
>> On Sep 19, 2017, at 7:02 PM, Adam Lewis <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Bill Burke <[email-masked]>
Date: Tue, 19 Sep 2017 20:44:55 -0400

Cookies are vulnerable to CXRF.

On Tue, Sep 19, 2017 at 7:48 PM, nov matake <[email-masked]> wrote:
> If the app can interact with AuthZ server through a hidden iframe with
> prompt=none param, you shouldn’t need refresh tokens.
>
> If your SAP is running on a different domain with the backend server,
> Safari’s Intelligent Tracking Prevention will break the hidden iframe way
> though.
>
> However with bearer tokens it is still riskier than code with a confidential
> client so the AS should take that into account and not allow refresh tokens
> to live forever.
>
> One future way to protect refresh tokens and perhaps Access tokens is to use
> token binding to bind the tokens to the user agent.   You could do that now
> for refresh tokens in Edge (Chrome has TB off by default still).
>

-- 
Bill Burke
Red Hat

---

From: Jim Manico <[email-masked]>
Date: Wed, 20 Sep 2017 09:31:48 +0800

Not always, Bill. There is a new standard called "same site cookies" or "first party cookies" that allows you to programmatically remove this risk in some modern browsers, it's worth reviewing. 

https://tools.ietf.org/html/draft-west-first-party-cookies-07

It's live in Chrome and Opera and will only grow in support. http://caniuse.com/#search=samesite

Jim

> On Sep 20, 2017, at 8:44 AM, Bill Burke <[email-masked]> wrote:
>

---

From: Nov Matake <[email-masked]>
Date: Wed, 20 Sep 2017 11:11:29 +0900

you have redirect uri restriction there.

nov

> On Sep 20, 2017, at 9:44, Bill Burke <[email-masked]> wrote:
>

---

From: Josh Mandel <[email-masked]>
Date: Tue, 19 Sep 2017 23:58:46 -0400

Can anyone provide insight about what protection PKCE adds for browser
based apps using the authorization code flow? The PKCE intro says that the
specification is designed to mitigate an attack where:

> the attacker intercepts the authorization code returned from the
authorization endpoint within a communication path not protected by
Transport Layer Security (TLS), such as inter-application communication
within the client's operating system

... but for a browser based client, I'm not clear on why this is important.
(I agree PKCE doesn't hurt, of course, but I'm trying to understand whether
there is a specific advantage.)

Thanks for any perspective that,

Josh

On Sep 19, 2017 21:11, "Nov Matake" <[email-masked]> wrote:

> >> Right,  Refresh token is bearer for native apps, that is why we came up
> with
> >> PKCE to protect code.
> >>
> >> On Sep 19, 2017, at 7:02 PM, Adam Lewis <adam.lewis@motorolasolutions.
> com>
> >> wrote:
> >>
> >>>>> On Tue, Sep 19, 2017 at 9:27 AM, Stefan Büringer <
> [email-masked]>
> >>>>> wrote:
> >>>>> Hi,
> >>>>>
> >>>>> be a security risk, compared to the Implicit Flow were no refresh
> token
> >>>>> is
> >>>>> exposed.
> >>>>>
> >>>>> P.S. I couldn't find that much on the internet regarding
> Authorization
> >>>>> Code

---

From: Neil Madden <[email-masked]>
Date: Wed, 20 Sep 2017 06:21:38 +0100

Is this growing in support? It seems like a good idea, but when I reviewed it recently the draft had expired almost a year ago and still only Chrome and Opera had implemented it. From the outside it looks as if it has (inexplicably) died. Do you know if there is some activity happening behind the scenes?

-- Neil

> On 20 Sep 2017, at 02:31, Jim Manico <[email-masked]> wrote:
>

---

From: Jim Manico <[email-masked]>
Date: Wed, 20 Sep 2017 14:49:38 +0800

While we did see android support in January 2017, Chrome and Opera only offered support a few months ago. FireFox has a bug on this with notes suggesting it will be rolled out in a year or so. And while the original RFC expired, it's being rolled into the cookie RFC per my understanding.

I also asked the author of this standard for additional commentary, I'll get back to you.

--
Jim Manico
@Manicode

> On Sep 20, 2017, at 1:21 PM, Neil Madden <[email-masked]> wrote:
>

---

From: Jim Manico <[email-masked]>
Date: Wed, 20 Sep 2017 15:22:21 +0800

PS: The RFC for SameSite cookies has moved to here. https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis

It's an approved standard and was rolled into the new cookie RFC.

Chrome support has a big impact on mobile and elsewhere. But I agree we need to see FireFox and Safari support and expect to see it within a year.

But that should not stop folks from using it today. It's backwards compatible with existing cookie behavior and is quite beautiful in it's
simplicity and power to defend against CSRF.

Aloha,
Jim

---

From: Bill Burke <[email-masked]>
Date: Thu, 21 Sep 2017 17:06:08 -0400

Back to the OP...Why would browser Javascript implementing Authz Code
flow with public client be vulnerable?  Not understanding how an XSS
attack could work in such a scenario.

On Wed, Sep 20, 2017 at 3:22 AM, Jim Manico <[email-masked]> wrote:
> PS: The RFC for SameSite cookies has moved to here.
> https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis
>
> Chrome support has a big impact on mobile and elsewhere. But I agree we need
> to see FireFox and Safari support and expect to see it within a year.
>
> But that should not stop folks from using it today. It's backwards
> compatible with existing cookie behavior and is quite beautiful in it's
> Is this growing in support? It seems like a good idea, but when I reviewed
> it recently the draft had expired almost a year ago and still only Chrome
> and Opera had implemented it. From the outside it looks as if it has
> (inexplicably) died. Do you know if there is some activity happening behind
> the scenes?
>
> -- Neil
>
> Not always, Bill. There is a new standard called "same site cookies" or
> "first party cookies" that allows you to programmatically remove this risk
> in some modern browsers, it's worth reviewing.
>
> Right,  Refresh token is bearer for native apps, that is why we came up with
>
> PKCE to protect code.
>
>
> For Angular the code flow with PKCE is probably better than the token
>
> response type.
>
>
> On Sep 19, 2017, at 7:02 PM, Adam Lewis <[email-masked]>
>
> wrote:
>
>
> Except a refresh token is not purely bearer. The client is required to
>
> authenticate to use it.
>
>
> Phil
>
>
> On Tue, Sep 19, 2017 at 9:27 AM, Stefan Büringer <[email-masked]>
>
> wrote:
>
> Hi,
>
>
> I'd just like to ask if the Authorization Code Flow with PKCE is a
>
> valid
>
> option for Single-Page-Applications (in our case Angular), because
>
> Implicit
>
> be a security risk, compared to the Implicit Flow were no refresh token
>
> is
>
> exposed.
>
>
> P.S. I couldn't find that much on the internet regarding Authorization
>
> Code
>
> posts

-- 
Bill Burke
Red Hat