And I agree, Brock. CSP-3 policies that use strict-dynamic and nonces are fairly straight forward to deploy and provide backwards compatibility down to CSP 2 and 1. I yearn for a world where token binding and CSP are commonplace so I can sleep again! Until then, these solutions are fragile at best in the face of XSS.
Aloha, -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On May 18, 2018, at 12:53 PM, Brock Allen <brockal...@gmail.com> wrote: > > Fair enough, and I'm happy that this discussion has started. > > For now, IMO, CSP is a big help in protecting these types of apps. Token > binding will of course help too, once it's available/practical. > > -Brock > >> On 5/18/2018 12:47:49 PM, 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 for Windows 10 >> >> >> >> From: Brock Allen >> Sent: Friday, May 18, 2018 6:36 PM >> To: John Bradley; David Waite; Hannes Tschofenig >> Cc: 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 >> >> >> >> On 5/18/2018 12:27:48 PM, John Bradley <ve7...@ve7jtb.com> wrote: >> >> Yes that was the original intent to have the AT be short lived and refresh >> the AT via the authorization endpoint based on the session cookie. >> >> The session cookie should also be flagged as http only to protect it. >> >> Having a refresh token in local storrage may introduce new security issues >> unless it is token bound. >> >> Understanding the security issues of the code flow in the browser is >> important, before any new recommendation. >> >> John B. >> >> From: Brock Allen >> >> Sent: Friday, May 18, 2:46 PM >> >> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? >> >> To: David Waite, Hannes Tschofenig >> >> Cc: oauth@ietf.org >> >> >> One thing I maybe should have listed in the pros/cons in my original email >> is session management and token lifetime considerations, keeping in mind the >> original intent of the implicit flow. >> >> What I mean is that with implicit grant type, the client's ability to get >> new access tokens is limited to the user's session at the AS/OP. Obviously >> other flows make more sense to obtain longer lived access (via refresh >> tokens), but I don't know about a browser-based JS app. In a sense there's a >> bit of protection for the end user built into that design by virtue of being >> tied to the user's cookie at the AS/OP. >> >> Just throwing that out as an additional discussion point. >> >> -Brock >> >> On 5/18/2018 6:04:47 AM, David Waite <da...@alkaline-solutions.com> wrote: >> >> I have written some guidance already (in non-RFC format) on preferring code >> for single page apps, and other security practices (CORS, CSP). From the AS >> point of view, it aligns well with the native apps BCP. There are benefits >> of thinking about native and SPA apps just as ‘public clients’ from a >> policy/properties point of view. It also greatly simplifies OAuth/OIDC >> support on both the AS administrator and client developer side when >> converting web properties into native apps using technologies like Electron >> or Cordova. >> >> For the later requirements in the list around token policy, I am not sure >> these are requirements for single page apps per se. I don’t believe the need >> for a policy using short-lived refresh tokens, revoking at signout, or use >> of the revocation endpoint are different from browser and native >> applications. Rather they seem to be a function of usage patterns that an AS >> may need to support, and we happen to sometimes associate those usage >> patterns with typical usage of native apps vs of browser apps. For example, >> browser login on a borrowed device can easily leak over to being app >> authorization - the authentication/authorization are web-based processes to >> achieve SSO. >> >> I have been working on some guidance here around token lifetimes and >> policies, but I don’t know whether that brings in too much AS/OP business >> logic (and, likely implied product/deployment features) to be industry >> practices. >> >> -DW >> >> On May 17, 2018, at 10:23 AM, Hannes Tschofenig <hannes.tschofe...@arm.com> >> wrote: >> >> Hi Brock, >> >> >> >> there have been several attempts to start writing some guidance but so far >> we haven’t gotten too far.. >> >> IMHO it would be great to have a document. >> >> >> >> Ciao >> >> Hannes >> >> >> >> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brock Allen >> >> Sent: 17 May 2018 14:57 >> >> To: oauth@ietf.org >> >> Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps? >> >> >> >> Much like updated guidance was provided with the "OAuth2 for native apps" >> RFC, should there be one for "browser-based client-side JS apps"? I ask >> because google is actively discouraging the use of implicit flow: >> >> >> >> https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 >> >> >> >> From what I can tell, the complaints with implicit are: >> >> * access token in URL >> >> * access token in browser history >> >> * iframe complexity when using prompt=none to "refresh" access tokens >> >> >> >> But this requires: >> >> * AS/OP to support PKCE >> >> * AS/OP to support CORS >> >> * user-agent must support CORS >> >> * AS/OP to maintain short-lived refresh tokens >> >> * AS/OP must aggressively revoke refresh tokens at user signout (which is >> not something OAuth2 "knows" about) >> >> * if the above point can't work, then client must proactively use revocation >> endpoint if/when user triggers logout >> >> >> >> Any use in discussing this? >> >> >> >> -Brock >> >> >> >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy the >> information in any medium. Thank you. >> _______________________________________________ >> >> 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
