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
