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

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 <bburke@redhat.com> wrote:
> 
> Cookies are vulnerable to CXRF.
> 
>> On Tue, Sep 19, 2017 at 7:48 PM, nov matake <matake@gmail.com> 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 <ve7jtb@ve7jtb.com> 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 <adam.lewis@motorolasolutions.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) <phil.hunt@oracle.com>
>> 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 <bburke@redhat.com> 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
>>>> longer....Still, if you did the implicit flow, you'd have to have
>>>> longer access token timeouts as it would be really annoying for the
>>>> user to have to login again and again in a long session with your
>>>> Angular app.
>>>> 
>>>> We have a javascript adapter that does Authz Code Flow with PKCE for
>>>> our Angular app.  It also does CORS checks on the code to token XHR
>>>> request just in case on the IDP side.
>>>> 
>>>>> On Tue, Sep 19, 2017 at 9:27 AM, Stefan Büringer <sbueringer@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
>>> 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