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 >> <mailto: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 >> <mailto: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 >> > <mailto: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 >> >> <mailto: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 >> >> <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 <mailto:OAuth@ietf.org> >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> >> > >> > >> > >> > -- >> > Bill Burke >> > Red Hat >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org <mailto:OAuth@ietf.org> >> > https://www.ietf.org/mailman/listinfo/oauth >> > <https://www.ietf.org/mailman/listinfo/oauth> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto: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
