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 <neil.mad...@forgerock.com> 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 <j...@manicode.com> 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 <bbu...@redhat.com> wrote: >>> >>> Cookies are vulnerable to CXRF. >>> >>>> On Tue, Sep 19, 2017 at 7:48 PM, nov matake <mat...@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 <ve7...@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.le...@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.h...@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 <bbu...@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 <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 >>>>> 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 >> _______________________________________________ >> 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
