Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
We're basically on the same page, I think. I Was just coming from the perspective that once you've solved the iframe problem (say via a library), then it's six and one, or half a dozen and another, so to speak. Of course if the spec were redone today, it would look different and able to take into consideration what we have available today. But you mention a 10-minute only access token. Without a refresh token, then you do have to resort back to the iframe, and then we're back at square one. But again, I'm still agreeing with you :) As for prompt=none and the OP/AS wanting to set static policy to prevent iframes (presumably you mean with XFO/CSP), I don't see that as a problem. In my experience, those response headers don't apply when the response is just a 302 back to the redirect uri. They only are take effect when the response is rendering HTML. So you can set those globally in your OP/AS and it can still handle prompt=none properly. Unless I'm misunderstanding your last point. -Brock On 5/18/2018 2:21:06 PM, David Waite wrote: On May 18, 2018, at 11:55 AM, Brock Allen mailto:brockal...@gmail.com]> wrote: > 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. Hidden frames and special params -- are those really the main concerns with implicit? They aren’t the only issues, no. The point was that you can use code flow instead of implicit, keep a 10 minute access token lifetime and no refresh token, and it doesn’t add new security concerns. The security concerns are around changing token policy once you are doing code flow, due to the execution environment of the browser. The main initial motivation around implicit was client simplicity (plus it was rather early for CORS). Once you are implementing a second iframe-based approach to discretely retrieve updated access tokens, the simplicity argument doesn’t hold. It is also an additional security consideration for the AS - ideally I want to reject my user authentication/consent content from being loaded in frames as a static policy, but now I need to allow it when prompt=none is set.. This isn’t a policy recommended anyplace, just something the developers may have to argue with against the security people so that their app can have a halfway decent experience. -DW I thought the access token being sent in the URL is a bigger concern, and that's why code+PKCE is a better approach. -Brock ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
What you call pessimism I call stating fact! 😎 This has nothing to do with SPA apps. Like Neil says any XSS in play and token binding, HTTPOnly and similar do nothing to protect you. This is any web app. And XSS defense in a complex app is rough. Take the time to study it! I’m happy to present on XSS defense in-depth to the Oath standard body community if you wish. It’s a lot more difficult to get right than most think. Once you have XSS, dang. Might as well just stick unsigned AT’s in URL’s. Aloha, -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On May 18, 2018, at 2:51 PM, Neil Madden wrote: > > 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 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 for Windows 10 > > > > From: Neil Madden > Sent: Friday, May 18, 2018 7:38 PM > To: John Bradley; Jim Manico > Cc: oauth@ietf.org > 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 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 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. &g
Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
100% and that’s a good point. Stolen tokens will no longer work under token binding but XSS that does “stored request forgery” is still the bane of all web based apps. No web app with XSS vulnerabilities is safe from “stored forged requests”, which means you really need to be bulletproof from XSS if you want secure web software. Token binding does not stop this at all. So escape! Sanitize HTML input! Use safe JS sinks! Handle client side JSON correctly! CSP that app. These are critical defenses if you want security on the web. Token binding helps if a token is stolen. It should no longer be effective or active when used in a different client. -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On May 18, 2018, at 1:38 PM, Neil Madden wrote: > > 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 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 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 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 >>> ne
Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
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 (mailto:ve7...@ve7jtb.com)> 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:neil.mad...@forgerock.com) > Sent: Friday, May 18, 2018 7:38 PM > To: John Bradley (mailto:ve7...@ve7jtb.com); Jim Manico > (mailto:j...@manicode.com) > Cc: oauth@ietf.org (mailto:oauth@ietf.org) > 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 > (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 > (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
Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
> On May 18, 2018, at 11:55 AM, Brock Allen wrote: > > > 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. > > Hidden frames and special params -- are those really the main concerns with > implicit? They aren’t the only issues, no. The point was that you can use code flow instead of implicit, keep a 10 minute access token lifetime and no refresh token, and it doesn’t add new security concerns. The security concerns are around changing token policy once you are doing code flow, due to the execution environment of the browser. The main initial motivation around implicit was client simplicity (plus it was rather early for CORS). Once you are implementing a second iframe-based approach to discretely retrieve updated access tokens, the simplicity argument doesn’t hold. It is also an additional security consideration for the AS - ideally I want to reject my user authentication/consent content from being loaded in frames as a static policy, but now I need to allow it when prompt=none is set. This isn’t a policy recommended anyplace, just something the developers may have to argue with against the security people so that their app can have a halfway decent experience. -DW > I thought the access token being sent in the URL is a bigger concern, and > that's why code+PKCE is a better approach. > > -Brock ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
> 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. Hidden frames and special params -- are those really the main concerns with implicit? Those are just different mechanics to do the same thing. IMO, iframes are just another way to "do" HTTP, albeit more clumsy and effort than XMLHttpRequest. And in my experience, prompt=none is easily done and well supported. Perhaps my perspective is skewed. I thought the access token being sent in the URL is a bigger concern, and that's why code+PKCE is a better approach. -Brock___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
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 for Windows 10 From: Neil Madden Sent: Friday, May 18, 2018 7:38 PM To: John Bradley; Jim Manico Cc: oauth@ietf.org 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 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 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 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 Tschofe
Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
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 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
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 (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 (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 > > (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. > > > > &
Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
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 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 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 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 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 end
Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
> 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. My conjecture is that it does not matter >>at all<< where you store tokens in relation to XSS. There is no secure place to store data in a browser in ways that cannot be abused by XSS. One XSS is complete compromise of the client. I’m happy to discuss in detail with POC’s offline if you like. HTTPOnly cookies do absolutely nothing to stop an attacker from leveraging XSS to forge requests through a victims browser, a much more common red team attack than trying to steal a cookie. And XSS resistant apps are illusive. For example .NET is missing core controls around XSS defense like a well maintained HTML sanitizer for HTML input. -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On May 18, 2018, at 12:53 PM, Brock Allen 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 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 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 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
Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
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 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 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 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 t
Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
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 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 On 5/18/2018 12:27:48 PM, John Bradley 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 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 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 [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 be
Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
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 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 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 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.
Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
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 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 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 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 someth
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 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 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 >>> 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 >>&g
Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
+1. I think this would be good to have. Phil > On May 17, 2018, at 9:23 AM, Hannes Tschofenig > 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
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 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 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 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 [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 [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://
Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
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 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 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 https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
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 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 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 [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 [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 [https://www.ietf.org/mailman/listinfo/oauth] ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
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 > 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 <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 > <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 > <https://www.ietf.org/mailman/listinfo/oauth> ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
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-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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth