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

[Jim Manico <[e-mail]>]

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