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