I don’t believe code flow today with an equivalent token policy as you have with implicit causes any new security issues, and it does correct _some_ problems. The problem is that you immediately want to change token policy to get around hidden iframes and special parameters.
Once you start trying to alter token policy (such as adding refresh tokens), you start to have new security considerations because of the execution environment of javascript in the browser. Specifically token exfiltration from the browser origin, which can be mitigated via token binding or service workers. You don’t need to exfiltrate a token for a third party to use a the associated access; they can inject behavior onto the page via XSS or a browser extension. This is not related to token lifetime policy, or the use of implicit vs code. This is the more immediate area where I see guidance being important - especially considering that token exfiltration becomes closer to a theoretical attack if the behavior of my app is controlled. -DW On May 18, 2018, at 10:47 AM, John Bradley <ve7...@ve7jtb.com> wrote: > > There are lots of issues with the current implicit flow around fragment > encoding as well. > > However moving the token used for refresh from being a HTTP only cookie to a > refresh token available in the DOM makes me uncomfortable without having > sufficient mitigations against XSS. > > The current flow is vulnerable to XSS for the AT, however if that is short > lived it restricts the damage. > > The better solution is token binding the AT and perhaps a RT. > > We need to start talking about it. There are issues around potentially using > service workers etc as well. > > So we should start but I am not sure of what the correct answer is yet. > > John B. > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 > > From: Brock Allen <mailto:brockal...@gmail.com> > Sent: Friday, May 18, 2018 6:36 PM > To: John Bradley <mailto:ve7...@ve7jtb.com>; David Waite > <mailto:da...@alkaline-solutions.com>; Hannes Tschofenig > <mailto:hannes.tschofe...@arm.com> > Cc: oauth@ietf.org <mailto:oauth@ietf.org> > Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? > > It sounds to me as if you're hesitant to recommend code flow (at least for > now) then for browser-based JS apps. > > -Brock >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
