This is really fantastic news. Thank you for sharing that John. I’m a lot more optimistic about timely adoption.
Aloha, -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On May 18, 2018, at 12:53 PM, John Bradley <ve7...@ve7jtb.com> wrote: > > Token binding was just approved by the IESG (one more editorial pass to > include some non normative input then on to the RFC editor) . > > It is enabled by default for Edge and IE on win 10. It is configurable on > Chrome but currently defaulted to off. > I expect that to change in the near future. > > Mozilla could use more resources so they can prioritize it. > > Safari is of course anyone’s guess. > > I don’t expect it to be years before it deployed widely enough to support. > > John B. > > Sent from Mail for Windows 10 > > From: Jim Manico > Sent: Friday, May 18, 2018 6:43 PM > To: John Bradley > Cc: David Waite; Hannes Tschofenig; Brock Allen; oauth@ietf.org > Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps? > > 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> 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
