Ha! Well it was Jim Manico’s pessimism about http-only cookies that started it! :-)
I agree with Jim about http-only, and I agree with you that token binding has lots of other good advantages. But pretty much all security is lost if XSS is a possibility. Even storing secrets on the server does not help much as if I can forge requests from the same origin then I can probably trick the server into performing actions on my behalf too. Preventing/mitigating XSS is crucial (CSP is a big help), but that is not specific to OAuth. — Neil > On Friday, May 18, 2018 at 6:46 pm, John Bradley <[email protected] > (mailto:[email protected])> wrote: > > You cant extract a token bound cookie or AT and use it in a different user > agent. > > > > > > You could still force the user agent to use a token bound cookie itself.. > > > > > > For the AT and refresh they are not cookies so they need to sent by the JS so > may be harder to trigger? > > > > > > I thought I was the pessimistic one😊 > > > > > > SPA may turn out to be impossible to completely secure. However that wont > stop people from creating them. > > > > > > We can try to put together the best advice, and limit the damage. > > > > > > John B. > > > > > > Sent from Mail (https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10 > > > > > > From: Neil Madden (mailto:[email protected]) > Sent: Friday, May 18, 2018 7:38 PM > To: John Bradley (mailto:[email protected]); Jim Manico > (mailto:[email protected]) > Cc: [email protected] (mailto:[email protected]) > Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? > > > > > > > I might be missing something here, but aren’t bound tokens exactly as > vulnerable to the XSS attacks you describe as http-only cookies are? > > > > > > > — Neil > > > > > > > > > > On Friday, May 18, 2018 at 5:43 pm, Jim Manico <[email protected] > > (mailto:[email protected])> wrote: > > > > > > > > A few notes: > > > > > The session cookie should also be flagged as http only to protect it. > > > > > > > > > > > > > > This provides no real protection. If I get XSS into your site I don’t need > > to steal the cookie. I can just force requests that will automatically send > > it (client side or stored request forgery). So while it’s a standard > > suggestion, it helps little. > > > > > > > > > > > > > > > > > Having a refresh token in local storrage may introduce new security > > > issues unless it is token bound. > > > > > > > > > > > > > > > > Token binding is not live yet, right? If you need to store a token in a > > browser please note there is no safe place to store it. LocalStorage can be > > harvested by XSS and even the strongest cookies can be replayed as > > discussed above. I can’t wait for browser based token binding! But it will > > likely take years for this to be avail in the majority of browsers. > > > > > > > > > > > > > > > > > Understanding the security issues of the code flow in the browser is > > > important, before any new recommendation. > > > > > > > > > > > > > > > > Well said. It looks to be the only secure workflow for browser based apps. > > Love it how passwords are kept away from RP’s and high powered tokens are > > not stored in the browser. > > > > > > > > > > > > > > > > Aloha, > > > > > > -- > > > > > > > > Jim Manico > > > > > > > > @Manicode > > > > > > > > Secure Coding Education > > > > > > > > +1 (808) 652-3805 > > > > > > > > > > > > On May 18, 2018, at 12:27 PM, John Bradley <[email protected] > > (mailto:[email protected])> 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: [email protected] (mailto:[email protected]) > > > > > > > > > > > > > > > > > > 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 <[email protected] > > > > (mailto:[email protected])> 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 > > > > > <[email protected] (mailto:[email protected])> 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:[email protected]] On Behalf Of Brock Allen > > > > > > > > > > > > > > > > > > > > Sent: 17 May 2018 14:57 > > > > > > > > > > > > > > > > > > > > To: [email protected] (mailto:[email protected]) > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > [email protected] (mailto:[email protected]) > > > > > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > [email protected] (mailto:[email protected]) > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > > > > >
signature.asc
Description: PGP signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
