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

[Brock Allen]

We're basically on the same page, I think. 

I Was just coming from the perspective that once you've solved the iframe 
problem (say via a library), then it's six and one, or half a dozen and 
another, so to speak. Of course if the spec were redone today, it would look 
different and able to take into consideration what we have available today.

But you mention a 10-minute only access token. Without a refresh token, then 
you do have to resort back to the iframe, and then we're back at square one. 
But again, I'm still agreeing with you :)

As for prompt=none and the OP/AS wanting to set static policy to prevent 
iframes (presumably you mean with XFO/CSP), I don't see that as a problem. In 
my experience, those response headers don't apply when the response is just a 
302 back to the redirect uri. They only are take effect when the response is 
rendering HTML. So you can set those globally in your OP/AS and it can still 
handle prompt=none properly. Unless I'm misunderstanding your last point.

-Brock

On 5/18/2018 2:21:06 PM, David Waite  wrote:


On May 18, 2018, at 11:55 AM, Brock Allen  wrote:

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


Hidden frames and special params -- are those really the main concerns with 
implicit?

They aren’t the only issues, no. The point was that you can use code flow 
instead of implicit, keep a 10 minute access token lifetime and no refresh 
token, and it doesn’t add new security concerns. The security concerns are 
around changing token policy once you are doing code flow, due to the execution 
environment of the browser.

The main initial motivation around implicit was client simplicity (plus it was 
rather early for CORS). Once you are implementing a second iframe-based 
approach to discretely retrieve updated access tokens, the simplicity argument 
doesn’t hold.

It is also an additional security consideration for the AS - ideally I want to 
reject my user authentication/consent content from being loaded in frames as a 
static policy, but now I need to allow it when prompt=none is set.. This isn’t 
a policy recommended anyplace, just something the developers may have to argue 
with against the security people so that their app can have a halfway decent 
experience.

-DW

I thought the access token being sent in the URL is a bigger concern, and 
that's why code+PKCE is a better approach.


-Brock
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Jim Manico]

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.mad...@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 <ve7...@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 <j...@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 <ve7...@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 manageme

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

[Jim Manico]

100% and that’s a good point. Stolen tokens will no longer work under token 
binding but XSS that does “stored request forgery” is still the bane of all web 
based apps.

No web app with XSS vulnerabilities is safe from “stored forged requests”, 
which means you really need to be bulletproof from XSS if you want secure web 
software. Token binding does not stop this at all.

So escape! Sanitize HTML input! Use safe JS sinks! Handle client side JSON 
correctly! CSP that app. These are critical defenses if you want security on 
the web.

Token binding helps if a token is stolen. It should no longer be effective or 
active when used in a different client.
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On May 18, 2018, at 1:38 PM, Neil Madden <neil.mad...@forgerock.com> wrote:
> 
> 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 <j...@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 <ve7...@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 <da...@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 
>>

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

[Neil Madden]

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 <ve7...@ve7jtb.com 
> (mailto:ve7...@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 (https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10
>
>
>
>
>
> From: Neil Madden (mailto:neil.mad...@forgerock.com)
> Sent: Friday, May 18, 2018 7:38 PM
> To: John Bradley (mailto:ve7...@ve7jtb.com); Jim Manico 
> (mailto:j...@manicode.com)
> Cc: oauth@ietf.org (mailto: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 <j...@manicode.com 
> > (mailto:j...@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 <ve7...@ve7jtb.com 
> > (mailto:ve7...@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 securi

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

[David Waite]

> On May 18, 2018, at 11:55 AM, Brock Allen  wrote:
> 
> > 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.
> 
> Hidden frames and special params -- are those really the main concerns with 
> implicit?

They aren’t the only issues, no. The point was that you can use code flow 
instead of implicit, keep a 10 minute access token lifetime and no refresh 
token, and it doesn’t add new security concerns. The security concerns are 
around changing token policy once you are doing code flow, due to the execution 
environment of the browser.

The main initial motivation around implicit was client simplicity (plus it was 
rather early for CORS). Once you are implementing a second iframe-based 
approach to discretely retrieve updated access tokens, the simplicity argument 
doesn’t hold.

It is also an additional security consideration for the AS - ideally I want to 
reject my user authentication/consent content from being loaded in frames as a 
static policy, but now I need to allow it when prompt=none is set. This isn’t a 
policy recommended anyplace, just something the developers may have to argue 
with against the security people so that their app can have a halfway decent 
experience.

-DW

> I thought the access token being sent in the URL is a bigger concern, and 
> that's why code+PKCE is a better approach.

> 
> -Brock

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Brock Allen]

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


Hidden frames and special params -- are those really the main concerns with 
implicit? Those are just different mechanics to do the same thing. IMO, iframes 
are just another way to "do" HTTP, albeit more clumsy and effort than 
XMLHttpRequest. And in my experience, prompt=none is easily done and well 
supported. Perhaps my perspective is skewed.

I thought the access token being sent in the URL is a bigger concern, and 
that's why code+PKCE is a better approach.

-Brock___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[John Bradley]

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 <j...@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 <ve7...@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 <da...@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 indust

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

[David Waite]

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 <ve7...@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:brockal...@gmail.com>
> Sent: Friday, May 18, 2018 6:36 PM
> To: John Bradley <mailto:ve7...@ve7jtb.com>; David Waite 
> <mailto:da...@alkaline-solutions.com>; Hannes Tschofenig 
> <mailto:hannes.tschofe...@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
>  
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Neil Madden]

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 <j...@manicode.com 
> (mailto:j...@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 <ve7...@ve7jtb.com 
> (mailto:ve7...@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 (mailto: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 <da...@alkaline-solutions.com 
> > > (mailto:da...@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-b

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

[Jim Manico]

And I agree, Brock. CSP-3 policies that use strict-dynamic and nonces are 
fairly straight forward to deploy and provide backwards compatibility down to 
CSP 2 and 1. I yearn for a world where token binding and CSP are commonplace so 
I can sleep again! Until then, these solutions are fragile at best in the face 
of XSS.

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

> On May 18, 2018, at 12:53 PM, Brock Allen <brockal...@gmail.com> wrote:
> 
> Fair enough, and I'm happy that this discussion has started. 
> 
> For now, IMO, CSP is a big help in protecting these types of apps. Token 
> binding will of course help too, once it's available/practical.
> 
> -Brock
> 
>> On 5/18/2018 12:47:49 PM, John Bradley <ve7...@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 for Windows 10
>> 
>>  
>> 
>> From: Brock Allen
>> Sent: Friday, May 18, 2018 6:36 PM
>> To: John Bradley; David Waite; Hannes Tschofenig
>> Cc: 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
>> 
>>  
>> 
>> On 5/18/2018 12:27:48 PM, John Bradley <ve7...@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 <da...@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

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

[Jim Manico]

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

My conjecture is that it does not matter >>at all<< where you store tokens in 
relation to XSS. There is no secure place to store data in a browser in ways 
that cannot be abused by XSS. One XSS is complete compromise of the client. I’m 
happy to discuss in detail with POC’s offline if you like. HTTPOnly cookies do 
absolutely nothing to stop an attacker from leveraging XSS to forge requests 
through a victims browser, a much more common red team attack than trying to 
steal a cookie.

And XSS resistant apps are illusive. For example .NET is missing core controls 
around XSS defense like a well maintained HTML sanitizer for HTML input. 

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

> On May 18, 2018, at 12:53 PM, Brock Allen <brockal...@gmail.com> wrote:
> 
> Fair enough, and I'm happy that this discussion has started. 
> 
> For now, IMO, CSP is a big help in protecting these types of apps. Token 
> binding will of course help too, once it's available/practical.
> 
> -Brock
> 
>> On 5/18/2018 12:47:49 PM, John Bradley <ve7...@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 for Windows 10
>> 
>>  
>> 
>> From: Brock Allen
>> Sent: Friday, May 18, 2018 6:36 PM
>> To: John Bradley; David Waite; Hannes Tschofenig
>> Cc: 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
>> 
>>  
>> 
>> On 5/18/2018 12:27:48 PM, John Bradley <ve7...@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 <da...@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 a

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

[Brock Allen]

Fair enough, and I'm happy that this discussion has started. 

For now, IMO, CSP is a big help in protecting these types of apps. Token 
binding will of course help too, once it's available/practical.

-Brock

On 5/18/2018 12:47:49 PM, John Bradley <ve7...@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:brockal...@gmail.com]
Sent: Friday, May 18, 2018 6:36 PM
To: John Bradley [mailto:ve7...@ve7jtb.com]; David Waite 
[mailto:da...@alkaline-solutions.com]; Hannes Tschofenig 
[mailto:hannes.tschofe...@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
 
On 5/18/2018 12:27:48 PM, John Bradley <ve7...@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 <da...@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.tschofe...@arm.com 
[mailto:hannes.tschofe...@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-boun...@ietf.org [mailto:oauth-boun...@ietf.org]] On 
Behalf Of Brock Allen
Sent: 17 May 2018 14:57
To: oauth@ietf.org [mailto: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, 
shou

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

[John Bradley]

Token binding was just approved by the IESG (one more editorial pass to include 
some non normative input then on to the RFC editor) .

It is enabled by default for Edge and IE on win 10.  It is configurable on 
Chrome but currently defaulted to off.
I expect that to change in the near future.   

Mozilla could use more resources so they can prioritize it.  

Safari is of course anyone’s guess. 

I don’t expect it to be years before it deployed widely enough to support.  

John B.

Sent from Mail for Windows 10

From: Jim Manico
Sent: Friday, May 18, 2018 6:43 PM
To: John Bradley
Cc: David Waite; Hannes Tschofenig; Brock Allen; oauth@ietf.org
Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

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 <ve7...@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 <da...@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.tschofe...@arm.com> 
wrote:
Hi Brock,
 
there have been several attempts to start writing some guidance but so far

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

[Jim Manico]

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 <ve7...@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 <da...@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.tschofe...@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: 

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

[Phil Hunt]

+1. I think this would be good to have. 

Phil

> On May 17, 2018, at 9:23 AM, Hannes Tschofenig  
> 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-boun...@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

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

[Brock Allen]

It sounds to me as if you're hesitant to recommend code flow (at least for now) 
then for browser-based JS apps.

-Brock

On 5/18/2018 12:27:48 PM, John Bradley <ve7...@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 <da...@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.tschofe...@arm.com 
[mailto:hannes.tschofe...@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-boun...@ietf.org [mailto:oauth-boun...@ietf.org]] On 
Behalf Of Brock Allen

Sent: 17 May 2018 14:57

To: oauth@ietf.org [mailto: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 
[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. ___

OAut

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

[John Bradley]

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 <da...@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.tschofe...@arm.com<mailto:hannes.tschofe...@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-boun...@ietf.org] On Behalf Of Brock Allen
Sent: 17 May 2018 14:57
To: oauth@ietf.org<mailto: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<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Brock Allen]

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  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  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-boun...@ietf.org [mailto:oauth-boun...@ietf.org]] On 
Behalf Of Brock Allen
Sent: 17 May 2018 14:57
To: oauth@ietf.org [mailto: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 
[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 [mailto:OAuth@ietf.org]
https://www.ietf.org/mailman/listinfo/oauth 
[https://www.ietf.org/mailman/listinfo/oauth]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[David Waite]

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  
> 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-boun...@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

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

[Hannes Tschofenig]

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-boun...@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