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 <j...@manicode.com > (mailto:j...@manicode.com)> 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 <ve7...@ve7jtb.com > (mailto: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 (mailto: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 > > > (mailto: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 (mailto: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 (mailto: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 (mailto:OAuth@ietf.org) > > > > 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
signature.asc
Description: PGP signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
