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

[Bill Burke]

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  wrote:
> 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
>
> On Sep 20, 2017, at 1:21 PM, Neil Madden  wrote:
>
> 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  wrote:
>
> 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  wrote:
>
> Cookies are vulnerable to CXRF.
>
> On Tue, Sep 19, 2017 at 7:48 PM, nov matake  wrote:
>
> 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  wrote:
>
>
> 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 
>
> wrote:
>
>
> Only for confidential clients.  No authentication is required for public
>
> clients.
>
>
> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) 
>
> wrote:
>
>
> 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  wrote:
>
>
> 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
>
> longerStill, 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 
>
> wrote:
>
> 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 

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

[Jim Manico]

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

> On Sep 20, 2017, at 1:21 PM, Neil Madden  wrote:
> 
> 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  wrote:
>> 
>> 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  wrote:
>>> 
>>> Cookies are vulnerable to CXRF.
>>> 
 On Tue, Sep 19, 2017 at 7:48 PM, nov matake  wrote:
 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  wrote:
 
 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 
 wrote:
 
 Only for confidential clients.  No authentication is required for public
 clients.
 
 On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) 
 wrote:
> 
> 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  wrote:
>> 
>> 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
>> longerStill, 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 
>>> wrote:
>>> 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 

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

[Jim Manico]

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  wrote:
> 
> 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  wrote:
>> 
>> 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  wrote:
>>> 
>>> Cookies are vulnerable to CXRF.
>>> 
 On Tue, Sep 19, 2017 at 7:48 PM, nov matake  wrote:
 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  wrote:
 
 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 
 wrote:
 
 Only for confidential clients.  No authentication is required for public
 clients.
 
 On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) 
 wrote:
> 
> 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  wrote:
>> 
>> 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
>> longerStill, 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 
>>> wrote:
>>> 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
>>> 

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

[Neil Madden]

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  wrote:
> 
> 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  wrote:
>> 
>> Cookies are vulnerable to CXRF.
>> 
>>> On Tue, Sep 19, 2017 at 7:48 PM, nov matake  wrote:
>>> 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  wrote:
>>> 
>>> 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 
>>> wrote:
>>> 
>>> Only for confidential clients.  No authentication is required for public
>>> clients.
>>> 
>>> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) 
>>> wrote:
 
 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  wrote:
> 
> 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
> longerStill, 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 
>> wrote:
>> 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.
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> 
> 
> --
> Bill Burke
> Red Hat
> 
> ___
> 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] Recommendations for browser-based apps

[Josh Mandel]

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"  wrote:

> you have redirect uri restriction there.
>
> nov
>
> > On Sep 20, 2017, at 9:44, Bill Burke  wrote:
> >
> > Cookies are vulnerable to CXRF.
> >
> >> On Tue, Sep 19, 2017 at 7:48 PM, nov matake  wrote:
> >> 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  wrote:
> >>
> >> 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  com>
> >> wrote:
> >>
> >> Only for confidential clients.  No authentication is required for public
> >> clients.
> >>
> >> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) 
> >> wrote:
> >>>
> >>> 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  wrote:
> 
>  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
>  longerStill, 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 <
> sbuerin...@gmail.com>
> > wrote:
> > 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.
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> 
> 
> 
>  --
>  Bill Burke
>  Red Hat
> 
>  ___
>  OAuth mailing list
>  OAuth@ietf.org
>  https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >>> ___
> >>> OAuth mailing list
> >>> 

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

[Nov Matake]

you have redirect uri restriction there.

nov

> On Sep 20, 2017, at 9:44, Bill Burke  wrote:
> 
> Cookies are vulnerable to CXRF.
> 
>> On Tue, Sep 19, 2017 at 7:48 PM, nov matake  wrote:
>> 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  wrote:
>> 
>> 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 
>> wrote:
>> 
>> Only for confidential clients.  No authentication is required for public
>> clients.
>> 
>> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) 
>> wrote:
>>> 
>>> 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  wrote:
 
 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
 longerStill, 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 
> wrote:
> 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.
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
 
 
 
 --
 Bill Burke
 Red Hat
 
 ___
 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
>> 
>> 
>> ___
>> 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
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> 
> 
> -- 
> Bill Burke
> Red Hat

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

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

[Jim Manico]

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  wrote:
> 
> Cookies are vulnerable to CXRF.
> 
>> On Tue, Sep 19, 2017 at 7:48 PM, nov matake  wrote:
>> 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  wrote:
>> 
>> 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 
>> wrote:
>> 
>> Only for confidential clients.  No authentication is required for public
>> clients.
>> 
>> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) 
>> wrote:
>>> 
>>> 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  wrote:
 
 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
 longerStill, 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 
> wrote:
> 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.
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
 
 
 
 --
 Bill Burke
 Red Hat
 
 ___
 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
>> 
>> 
>> ___
>> 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
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> 
> 
> -- 
> Bill Burke
> Red Hat
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> 

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

[Bill Burke]

Cookies are vulnerable to CXRF.

On Tue, Sep 19, 2017 at 7:48 PM, nov matake  wrote:
> 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  wrote:
>
> 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 
> wrote:
>
> Only for confidential clients.  No authentication is required for public
> clients.
>
> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) 
> wrote:
>>
>> 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  wrote:
>> >
>> > 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
>> > longerStill, 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 
>> >> wrote:
>> >> 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.
>> >>
>> >> ___
>> >> OAuth mailing list
>> >> OAuth@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/oauth
>> >>
>> >
>> >
>> >
>> > --
>> > Bill Burke
>> > Red Hat
>> >
>> > ___
>> > 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
>
>
> ___
> 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
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



-- 
Bill Burke
Red Hat

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

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

[nov matake]

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  wrote:
> 
> 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 > > wrote:
>> 
>> Only for confidential clients.  No authentication is required for public 
>> clients.
>> 
>> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) > > wrote:
>> 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 > > > wrote:
>> >
>> > 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
>> > longerStill, 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 > >> > wrote:
>> >> 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.
>> >>
>> >> ___
>> >> OAuth mailing list
>> >> OAuth@ietf.org 
>> >> https://www.ietf.org/mailman/listinfo/oauth 
>> >> 
>> >>
>> >
>> >
>> >
>> > --
>> > Bill Burke
>> > Red Hat
>> >
>> > ___
>> > 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 
>> 
>> 
>> ___
>> 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

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

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

[John Bradley]

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  
> wrote:
> 
> Only for confidential clients.  No authentication is required for public 
> clients.
> 
> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM)  > wrote:
> 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  > > wrote:
> >
> > 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
> > longerStill, 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  >> > wrote:
> >> 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.
> >>
> >> ___
> >> OAuth mailing list
> >> OAuth@ietf.org 
> >> https://www.ietf.org/mailman/listinfo/oauth 
> >> 
> >>
> >
> >
> >
> > --
> > Bill Burke
> > Red Hat
> >
> > ___
> > 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 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Adam Lewis]

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

On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) 
wrote:

> 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  wrote:
> >
> > 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
> > longerStill, 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 
> wrote:
> >> 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.
> >>
> >> ___
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >
> >
> >
> > --
> > Bill Burke
> > Red Hat
> >
> > ___
> > 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Jim Manico]

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)  wrote:
> 
> 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  wrote:
>> 
>> 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
>> longerStill, 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  
>>> wrote:
>>> 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.
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>> 
>> 
>> 
>> -- 
>> Bill Burke
>> Red Hat
>> 
>> ___
>> 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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Phil Hunt (IDM)]

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  wrote:
> 
> 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
> longerStill, 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  
>> wrote:
>> 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.
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> 
> 
> -- 
> Bill Burke
> Red Hat
> 
> ___
> 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] Recommendations for browser-based apps

[Bill Burke]

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
longerStill, 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  wrote:
> 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.
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



-- 
Bill Burke
Red Hat

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

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

[Aaron Parecki]

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


On Wed, Jan 25, 2017 at 4:24 PM,  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  for
> Windows 10
>
>
>
> *From: *Aaron Parecki 
> *Sent: *January 25, 2017 3:12 PM
> *To: *OAuth WG 
> *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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[ve7jtb]

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 for Windows 10

From: Aaron Parecki
Sent: January 25, 2017 3:12 PM
To: OAuth WG
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




smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth