On Fri, Oct 28, 2022 at 7:07 PM Sasha Tokarev <alex...@microsoft.com> wrote:
> Hi John, > > > > Sorry for the delay. > > > > 1) Can we avoid modifying the Cookie header, and only modify "x-ms-" > headers? > > - No, in some version of windows we use Cookie instead of headers. > I'm not seeing why this is an issue? It's not difficult to check two different request headers, server-side. Cookies have web standard behavior, which these don't obey, so it seems safer to use a separate header, rather than provide APIs to manipulate Cookies within Chromium for the sake of things that are not cookies. > 2) Can this be scoped to just frame requests, e.g. only for requests to > fetch the html for main frames and subframes and not subresource requests > like images, XHR, JS, CSS etc. requests? Igor had tried this locally and it > seemed to work. > > > > - some customers have a proxy, which redirects to all requests, including > from images to their internal service, authenticates the user via AAD and > redirects back if this request is authorized to the user. Can you do it for > frame request only – yes, and it will cover most of the scenarios, but the > previous one will not work in Chrome. My recommendation would be to do in > all requests. > > > > Thank you, > > Sasha > > > > *From:* John Abd-El-Malek <j...@chromium.org> > *Sent:* Tuesday, October 18, 2022 12:58 PM > *To:* Sasha Tokarev <alex...@microsoft.com> > *Cc:* Matt Menke <mme...@chromium.org>; blink-dev <blink-dev@chromium.org>; > Owen Min <z...@chromium.org>; Greg Thompson <g...@chromium.org>; Ryan > Sleevi <rsle...@chromium.org>; Adam Langley <a...@chromium.org> > *Subject:* Re: [blink-dev] RE: [EXTERNAL] Re: Native support of Windows > SSO in Chrome > > > > You don't often get email from j...@chromium.org. Learn why this is > important <https://aka.ms/LearnAboutSenderIdentification> > > Hi Sasha, I got looped in to a code review and I had a few questions: > > > > 1) Can we avoid modifying the Cookie header, and only modify "x-ms-" > headers? > > 2) Can this be scoped to just frame requests, e.g. only for requests to > fetch the html for main frames and subframes and not subresource requests > like images, XHR, JS, CSS etc. requests? Igor had tried this locally and it > seemed to work. > > > > If we can do the above, either right away or with small changes to your > server, we can simplify the implementation in Chrome. This in turn would > help us reach a lower maintenance burden while still being performant. > > > > Thanks > > > > On Thu, Aug 11, 2022 at 4:30 PM 'Sasha Tokarev' via blink-dev < > blink-dev@chromium.org> wrote: > > With respect to credential mode “omit” it is fine not send those headers, > if the other mode will allow it. > > > > We use sandboxed iframes in out authentication libs, but we set > “allow-same-origin” token to be able to use cookies. > > > > > https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/6756b300c5696ad4890f1f7f27de69f6941a71e7/lib/msal-browser/src/interaction_handler/SilentHandler.ts#L143 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzureAD%2Fmicrosoft-authentication-library-for-js%2Fblob%2F6756b300c5696ad4890f1f7f27de69f6941a71e7%2Flib%2Fmsal-browser%2Fsrc%2Finteraction_handler%2FSilentHandler.ts%23L143&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716146352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=vS14Xw7x%2FQvSsDsyCFOzjXy22HfbHsTeP7qGnbfYYeM%3D&reserved=0> > > > > We fine if “allow-same-origin” will relax restriction of not sending > cookies. > > > > > https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FHTML%2FElement%2Fiframe%23attr-sandbox&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716146352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=dWrHKcXb7EVPimVkz%2FsUvbSEAYDhmstMlGKIPAj8ZvY%3D&reserved=0> > > > > Thank you, > > Sasha > > > > *From:* Matt Menke <mme...@chromium.org> > *Sent:* Thursday, August 11, 2022 3:09 PM > *To:* Sasha Tokarev <alex...@microsoft.com> > *Cc:* blink-dev <blink-dev@chromium.org>; Owen Min <z...@chromium.org>; > Greg Thompson <g...@chromium.org>; Ryan Sleevi <rsle...@chromium.org>; > Adam Langley <a...@chromium.org> > *Subject:* Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome > > > > > > > > On Thu, Aug 11, 2022 at 5:43 PM Sasha Tokarev <alex...@microsoft.com> > wrote: > > Hi Matt, > > > > I apologize for not being able to respond, I was on vacation, but now I’m > back. However, before the vacation, I had planned to ping this thread, as > we are getting more and more feedback that the extension model is not > working for various reasons, and the users do not have sufficient help to > resolve it. In many cases the extension is either accidentally dismissed, > or partially works (has icon on tab, but the rest functionality is > blocked). In such cases we suggest to escalate to Google, but I’ve been > seeing very few cases that successfully got attention from Google. > > > > You can read review feedback here: > > > > > https://chrome.google.com/webstore/detail/windows-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchrome.google.com%2Fwebstore%2Fdetail%2Fwindows-accounts%2Fppnbnpeolgkicgegkbkbjmhlideopiji&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716146352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=b%2F%2FNBSGW%2F97WYivO5807CiGo6Dz4VO8evx8FzwEavjU%3D&reserved=0> > > > > In such cases the only recommendation we have is “use Edge”, as it has the > native support and not a subject for the extension deployment issues. In > order to reduce support cost, we are also considering to change our > remediation page, which we show when the users hit the conditional access > issues, to detect such cases and show more explicit text to use Edge. I’m > hopping we will be able to make a progress on this. > > > > Back to your question: > > * Do we need to bypass CORS for requests send to Microsoft's IDP? > > - no you don’t need. It is ok to respect CORS. > > > > * Do we need to send Microsoft SSO credentials in Credentials Mode: Omit > requests? > > - I assume you meant this XHR requests with credentials? > https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#requests_with_credentials > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FHTTP%2FCORS%23requests_with_credentials&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716146352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=6zyZ8Hdx9YHiga6gaW3oBmoPqWNkZ8aI%2FZ%2BViCuBzRA%3D&reserved=0> > > We don’t use XHR for authentication for now. So, if it is > more simple, we can agree on “no”. > > > > No, I mean any request with a credentials mode of omit. See > https://fetch.spec.whatwg.org/#concept-request-credentials-mode > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffetch.spec.whatwg.org%2F%23concept-request-credentials-mode&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716146352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=GmN23x%2F%2BONho2vq1EHqYaKc93MhrP3eZyh55Yvu921w%3D&reserved=0>. > That's a fetch layer concept, not something unique to XHRs. > > > > > > * Do we need to send SSO credentials in sandboxed iframes of fenced frames? > > - no. I’ve synced up internally, we don’t use fenced > frames, but we use iframes (on the application page) for some > authentications. So, this headers should be available in iframes of the > application page. > > > > So what about sandboxed iframes? They don't have cookie access, normally. > > > > > > Thank you, > > Sasha > > > > *From:* Matt Menke mme...@chromium.org > *Sent:* Wednesday, July 20, 2022 8:52 AM > *To:* blink-dev <blink-dev@chromium.org> > *Cc:* Sasha Tokarev <alex...@microsoft.com>; Owen Min <z...@chromium.org>; > blink-dev <blink-dev@chromium.org>; Greg Thompson <g...@chromium.org>; > Ryan Sleevi <rsle...@chromium.org>; Adam Langley <a...@chromium.org>; Matt > Menke <mme...@chromium.org> > *Subject:* Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome > > > > This task is being picked up again, but there are a lot of questions in > terms of implementation: > > > > * Do we need to send Microsoft SSO credentials in Credentials Mode: Omit > requests? > > * Do we need to bypass CORS for requests send to Microsoft's IDP? This is > a bit related to the above question. > > * Do we need to send SSO credentials in sandboxed iframes of fenced frames? > > > > I'm hoping the answer to all of these is "no", so these behave a bit like > 3P cookies (which are being removed from the web platform...). > > On Wednesday, November 3, 2021 at 11:12:16 AM UTC-4 Sasha Tokarev wrote: > > (Sorry for duplication, but I don’t see this response in the public > thread, probably because I’ve sent it from my private email and it went to > some filters, so I’m repeating it from my official with some *additions*) > > > > I would like to highlight one important conception of “joined device". If > a user/admin went through the joining process, they *consented* and > expect: > > > > 1. browser SSO > 2. application SSO > 3. access to protected services from *a web and a native applications* > > > > Otherwise, they should not join. > > > > While privacy and security concerns are important, we should agree that it > is IDP job to balance all parties in process *of authentication*, and > they always exist, given we have centralized identity service, and IDP use > cookies. > > > > *Joining of the device is an explicit, and in some case not a trivial > action from a device owner (in case of personal devices the device owner == > the user), an extra flag in this process makes this feature unusable for > some cases. With respect to security and privacy aspects, there is no > essential difference in the IDP behavior between a web application and a > native application (browser SSO and application SSO), if the device owner > doesn’t like the IDP behavior, he/she needs to unjoin. * > > > > Thank you, > > Sasha > > > > > > *From:* Sasha Tokarev > *Sent:* Tuesday, November 2, 2021 6:33 PM > *To:* 'Matt Menke' <mme...@chromium.org> > *Cc:* Owen Min <z...@chromium.org>; blink-dev <blink-dev@chromium.org>; > Greg Thompson <g...@chromium.org>; Ryan Sleevi <rsle...@chromium.org>; > Adam Langley <a...@chromium.org> > *Subject:* RE: [EXTERNAL] Re: Native support of Windows SSO in Chrome > > > > Hi Matt, > > > > I missed that you asked some questions inline, sorry about that, I’ll > cover answers *inline* as well. > > > > *From:* Matt Menke <mme...@chromium.org> > *Sent:* Saturday, September 25, 2021 7:45 PM > *To:* Sasha Tokarev <alex...@microsoft.com> > *Cc:* Owen Min <z...@chromium.org>; blink-dev <blink-dev@chromium.org>; > Greg Thompson <g...@chromium.org>; Ryan Sleevi <rsle...@chromium.org>; > Adam Langley <a...@chromium.org> > *Subject:* Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome > > > > Thanks for the details, Sasha! Please don't feel like you need to answer > my questions while on vacation - there's no rush here. > > > > Enjoy your vacation! > > > > On Sat, Sep 25, 2021 at 9:22 PM Sasha Tokarev <alex...@microsoft.com> > wrote: > > Hi Matt, > > > > Disclaimer: I’m at vacation my responses may delay. > > > > *> What's the flow to join a cloud identity here? What are the permission > prompts like? I assume that home users who use generic home user Microsoft > accounts (as I believe encouraged during Windows install/configuration) > aren't assumed to be granting this permission, though it could reasonably > be described as a "device joined to cloud identity"?* > > > > There are many ways of joining devices, many of them looks like domain > joining, and requires admin’s action and explicit user action. Home user > also either go via explicit action and consent which include web SSO: > > [image: Graphical user interface, text, application Description > automatically generated] > > > > Thanks! So this is a per-local-app permission, that can also be > granted to all apps? (*Sasha: yes, if the user consents)* My main > concerns, in terms of privacy (not security issues) here are: > > > > 1. Home user using a Microsoft account on their personal device > unexpectedly gets logged in. If the user has to give explicit permission > to Chrome or all apps (apart from just using a Microsoft account), as it > sounds like is the case, I'm much less concerned about this. I'd still be > more comfortable if Chrome-side integration is disabled by default, though > the settings folk may not think it's worth a new setting. > > > > *Sasha: An extra settings just an extra friction, the user has consented, > and user expects SSO, otherwise it should not join the device.* > > > > 2) An enterprise uses corp Microsoft accounts, but doesn't want to use > Microsoft as an IDP. (*Sasha: it should not join device to Microsoft IDP > then)* It may not want this information to be sent to Microsoft. > Admittedly, I'm not sure how much of a concern this is, if Microsoft is > managing their accounts in the first place. Note that I'd be concerned > about this happening for non-Microsoft managed accounts here, too, just > think it's less likely for it to be possible to accidentally happen for > non-Microsoft accounts. Sounds like this does need explicit opt-in even > with Microsoft managed accounts, so sounds like this isn't at all an issue. > (*Sasha: Non-Microsoft accounts do not exist, but if they were, then I > don’t think it is an issue if the user has consented to it.)* > > > > 1. A bit less of a concern, but a person using their home account on a > corp device (not uncommon, though not generally a great idea), gets their > personal, non-corp managed account, sent to the IDP, inheriting the fact > that IDP is enabled on the device. It could either be using the corp IDP > configuration, or the IDP configuration associated with the domain of their > home account - both seem problematic to me. > > > > > > *Sasha: Currently, your personal cookie will not go to your organization’s > IDP, because our IDPs are segregated, and every IDP has associated list of > URLs, an IDP gets the cookie for its URL .However, if IDP handles both > personal and work identity, then it will get both cookies, and it will be > IDP’s job to ask the user which account he/she is going to use for this > application. However, there 2 things should happened for this scenario, the > IDP needs to handle both Organizational and Personal identity, the > application should be registered in a way that it handles personal and > organizational accounts. If that will happened, then the IDP will have to > ask the user which account to use, something like this: * > > > > 4) Enterprise intends to use the feature, but accidentally leaks this > information to a 3P. bouncing through the IDP. It sounds like there's > server-side configuration to prevent this, and given that the feature has > to be explicitly enabled on the OS, they've already indicated that they > trust their IDP. > > > > *Sasha: Admin needs to pre-install application in the tenant, otherwise it > will be rejetected. This concern also exists without this feature. A user > has Office, * > > 1. *the user logged in Office via IDP (login.microsoftonline.com > > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flogin.microsoftonline.com%2F&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716146352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=Ra3LapnCWETVb3f%2F5WCFZ5%2BWO2UFOJ3IctL%2B6UUjyIg%3D&reserved=0>)* > 2. *login.microsofonline.com > > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flogin.microsofonline.com%2F&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716146352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=ugOSrbP9uwXm4A62TCGaNlWIt1NCJMXGjIHFJNIIrPA%3D&reserved=0> > will store it as a cookie.* > 3. *Now, sasha.com > > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsasha.com%2F&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716302589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=tm5n1S5s5fNGYFOeGlKfkLpGlS2oVf2ZGZHd7XPY1I0%3D&reserved=0> > can silently bounce the user via login.microsfotonline.com > > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flogin.microsfotonline.com%2F&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716302589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=qflr4%2FsQuiiOt%2FD0fD6Dvjc%2BEjSZ3CTl7O%2F1OdgGt48%3D&reserved=0>, > get a token and read user’s email. It is a huge issue, if it would be > possible.* > > > > *That is why:* > > *Before sasha.com > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsasha.com%2F&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716302589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=tm5n1S5s5fNGYFOeGlKfkLpGlS2oVf2ZGZHd7XPY1I0%3D&reserved=0> > start to work in the tenant, admin needs to pre-install/pre-consent the > application in the tenant.* > > > > *I’m on purpose drawing parallel with cookie, because in this proposal, > the only thing we append a way how we deliver the cookie, the remaining > model stays the same. All threats that applicable for cookies, are also > applicable for this model.* > > > > Configure the admin consent workflow - Azure AD | Microsoft Docs > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fmanage-apps%2Fconfigure-admin-consent-workflow&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716302589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=W3N9Nzkk%2FwWBO79tSVu2Sxqp7Z5OqJoGOsDyqs99hIQ%3D&reserved=0> > > > > *> Would this be enabled by default (for enterprise users only)? * > > > > It is like domain join, when you join device to domain you expect SSO. > Given that there is explicit user or admin action, and consent, which > includes web SSO, it should be enabled by default both for consumers and > enterprise users, like it is enabled in Edge. Additional flags will only > complicate deployment and doesn’t bring extra protection, users will have > to remember about the extra flag. It decreases effectiveness of the > feature. > > > > We do not ask to deploy extra flags to enable Windows Integrated Auth, > once you joined to the domain you got it, this is a new versions of Windows > Integrated Authentication. > > > > *> Also, what about incognito? * > > > > In incognito it must be OFF by default, to protect user and organization, > but it is OK, to have a settings controllable by admin to make it on. > > > > *> So this means **evil.com* > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fevil.com%2F&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716302589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=ZHvTLgexX9TKxFx5njsDiUwmXGWhodlnnzGPVdqG88I%3D&reserved=0>* > could redirect to **https://login.microsoftonline.com/* > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flogin.microsoftonline.com%2F&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716302589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=k42HlQPwKGq%2FuDNel0RwdK%2Bvt%2F63maD7gVPSiT1w3n0%3D&reserved=0>*, > and tell it to log in using the IDP to **https://www.mywork.com* > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mywork.com%2F&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716302589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=bqmUPwQ539HT55eNIMdElr7Njuvc7kPAMIX%2FUDCdk5w%3D&reserved=0>*, > by providing a redirect URI there? Or is the referrer to the IDP validated > in some way?* > > > > I’m not sure I fully understand the attack here. Evil.com will have to use > mywork.com > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mywork.com%2F&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716302589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=bqmUPwQ539HT55eNIMdElr7Njuvc7kPAMIX%2FUDCdk5w%3D&reserved=0>’s > redirect URI, it means that token (authentication artifact) will be > delivered to https://www.mywork.com > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mywork.com%2F&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716302589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=bqmUPwQ539HT55eNIMdElr7Njuvc7kPAMIX%2FUDCdk5w%3D&reserved=0> > not to evil.com > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fevil.com%2F&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716302589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=ZHvTLgexX9TKxFx5njsDiUwmXGWhodlnnzGPVdqG88I%3D&reserved=0>. > Overall, these kinds of threats covered by federation protocols OIDC, > OAuth, SAML etc. IDPs exist in the modern world (Facebook, Google, AAD, > MSA) they have to be protected from all kinds of threats, as they > authenticate the user and redirect the token. All these IDPs produce a > cookie for themselves to avoid useless re-auth. This proposal only manages > the way of more secure delivering those cookies from native component in > OS, which must be implemented by IDPs vendors, to IDPs web site. This > proposal doesn’t change protocols how an IDP talks with web applications > (aka resources, aka target resources, aka relying parties). All threats and > mitigation applied to existing protocols. > > > > I'm not suggesting a threat here, just trying to understand what > information is used by the server to authenticate users (which, sure, I > want to know so I can figure out the worst that can happen in the case of a > malicious actor). > > > > *Sasha: in the moment of Windows logon, or application logon the IDP web > site creates an encrypted blob, that has user information, device > information and session key. Nobody except server can decrypt this blob. We > call this blob as PRT or authentication artifact. When a web request goes > to IDP, and only to IDP (not other web site), we take request QS parameters > that may include nonce, PRT and sign this request by the session key that > stored in TPM. When the request reaches the server, we:* > > 1. *Validate nonce.* > 2. *Decrypt PRT, extract Session key from it.* > 3. *Validate signature of the cookie.* > 4. *If the signature is valid, the server takes device id and user id > information from the blob.* > > > > *Here is example of the cookie, you can use any JWT parser to decode to > some level, > eyJhbGciOiJIUzI1NiIsICJjdHgiOiIwcDRXekZ6TlF1TnhjakRCRjBlOUtNQk9nSXNlUDdZMSJ9.eyJyZWZyZXNoX3Rva2VuIjoiSUFRQUJBQUFBQUFBbS0wNmJsQkUxVHBWTWlsOEtQUTQxNEhpZllLbVIwcTBOdlZ5SXYwNlY4Ujc2Rkt3SzV4SWd6NHlXMUJBSU5QNXZEekl4VGc4cXV1V25oaVY4TDEzZHIyNWtNVWxMU0t2VDVTcEFrNEhKQnRDTTFKbm43dzlZRkpCWlBoWnFwcE5lOXIzWGxEV0NLOFkwWVhoRC0wQV8yTkVIRkQzbG1RcEdNd1VkcGUtS2hiWjBNNDZ0aTFsYkVVR2RGNWRuc0c1R1pYYThoNzdTV1Fqay1TY2NETVA2Tnh0aDNRQzhRYV9zZ255Q2FQYVZKanBZaVhFYmFIajNTb0RDYS1Yb1RHQ192Q2JpaVhQX2NyWFZtSVhzQkZBSDg1WnFqYUhQYThlVTYwMTVINThOTmVJTll5VTlsVDFYeXZmanE5RXZ2QloyR1RIRU02MnNJWXR2SmkzQk1SeGJoLXB1cEV0UVpfY1doNEdLSXVBM2JrMFdHdUZVT3pnQmpGaERyWUk5aDJJLVVXUGF3cHFiTFJXbEZmejk5VDFsMnlFYVZlQ29uemotSHZYSVBCVjZfaEU0TUtYajh2T1pqV3ltelVnQmtvMVhqQlNyWkg4ZG1MMm9oX1BBU29oQWN4c2h2LXAwU05FTW1tQ1hPa1VwU2t0aXNhZkxNYUY5SnhMVW80dGVYanFLc1NDT2o0QURfYjZhQ2MybEY1dnpQWTdZNjdMVlVYZDRvYmkyX2RpOXJDbVQtLWVacXRHY25kMENUQmFvTWh5U0RrMTlqcVE5QVF0dGFRTnV6OTV3LVVCaEEyd09wRzVnaVNLM2tOOEhfZ0VhSF9ubjdaX2FQeU1GR1BfQ0VxNWppZTJjOGF5aWdmX2tjdjNHSWVfVGhfeFROSThjNE5JaWp2NWdCaEpCWU15R0NVejJfMEg2MnRUenJac1ZRYTIwTmphZlpVd3pxQ24xTDIwUnJNcUF4U2dwQzlYc1ZTcWY0WDEtRDBQRDB4WjdyYWR5U2RoWkV2X0FIV05PWGhiUk5oLXktem5JYV9LV2lvcnRxSWw3aW05ZzVWZzFmUTZuLThxUTRkWTUxM1pOTUI1SG03dks2emlJM19ORFdBUmdWU1VjekRGaUNnQ0lUWlVjdGQ2eW5Xbk9ZNnFiaVAxMFJjejZ2T2VjMzNsUHhaWTI2VnkwN1UwLUtHUEZnYlB4NmViM0dwY1c0MElLdmVaT2dnM2VDdkx1MkM0MHhsSnJYcnhEVmZBMGY2bTh3VWktVENRLWJEc2tzNEF3S1VHRk1YSUlzeF9ZaVlEMWd6OGoxYTJyRS1JVnM0OVJCMDNCQjlla2cwUVV4X2NPS0Z3dnpXdWt6Vkd4dFY0SWVjMGVXa21pLW9aR1NxVXVrWlpGMHdqZmpYckxBTExiTEQ2QmZQSl9oRGxxMnNGcHFibGtrN0tGMmZiQ0hudm03eFN0ZTYwMzlZRGNrZ3FpU3pfb3FhYk5Kb2JWdFdoRGNNNDlnb29SdXdpNERJbC1EVjFUWVhucVBpSnl1WWpOQlM5WjE2S2ZZQmtKdGtwblhlbW8tSDh0YlRNaUNvZXF1eEZFTFJKc0MxU0xEVUVQbjl5eEVaLWFlRno4N2xRNC1KQk9feHNxM09BWFMydXNJd3U0ZmpSTkRPM25QMllUYmFRTlNxamNvYnV3T1RMSGJJNVV3UFlTU19nUkFPdkRGbi1hNDRudWN0azBKcExTVXRrQVlFajBFWmVwYjIySDFfOTctal9fNERvM0FxVTBQTURfNFJUM1preHgyMUJJdkxmUWt1XzU3dVZ3WGtNdzNud2JxTUJKSUFBIiwgImlzX3ByaW1hcnkiOiJ0cnVlIiwgInJlcXVlc3Rfbm9uY2UiOiJBUUFCQUFBQUFBQW0tMDZibEJFMVRwVk1pbDhLUFE0MVhKWmVNb3MxSmxubzZuZXNBbVR1VEl2VTdLZUs3LXZab1dJR0JGdmNzZHNtb1ZUR2ZxOHdNZlVYRW9sRWE0c1h2bXZPQjBtemdNV0V4bFdhbTUzNWZDQUEifQ.ah99UVhYNBp2KoKx5I3yLbzdf01nV0nicPPCf43uMMw* > > > > *However, you will not be able to open refresh_token field, as it is > encrypted by a server key.* > > > > What happens if the cookie is rejected? > > > > *Sasha: IDP will try to ask username and password, 2FA, however if the > admin wants to validate the state of device, and device will not be > delivered, the user will blocked.* > > > > Could an MitM attacker figure out if the cookie is rejected or not > by whether the user was redirected from the IDP to the destination site? > > > > *Sasha: this question I didn’t fully understand. Overall MitM can conclude > that cookie was rejected.* > > > > *> I believe the initial proposed CL I saw wiring this up added the > cookies to all requests to the magic URL. Does this mean that only main > frame navigations need these additional cookies?* > > > > No, all navigations. It is a cookie by nature, it must follow all cookie > rules. If XHR-web request should append a cookies, then we need append this > cookie. The difference between this cookie and regular cookie is regular > cookie is not protected, an attacker can steal it and use on a different > device. This cookie is protected. Attacker can steal it but it will be > expired very fast. > > > > So not just all navigations, but also XHRs and subresource requests, then? > (*Sasha: yes if they go to IDP*) What about internal Chrome requests? > (*Sasha: > Chrome is not integrated with IDPs that on Windows, but if it will – then > yes)* These are non-webby requests, but I believe some enterprise > policies may trigger them (e.g., installing extensions mandated by group > policy). (*Sasha: I don’t think we care about them, these requests do not > have integration with our IDP.*) > > > > Should enabling 3P cookie blocking also block these, in contexts where we > consider the IDP server a 3P server? > > > > These sound like SameSite=None cookies, which are slated for removal from > the web platform. Admittedly, partitioned cookies will be added before > that, though since these aren't really partitioned, it's not accurate to > call these partitioned cookies, since they give a cross-site identity. > Clearing all cookies also clears cookies (whether the user does it, or it's > done by a Clear-Site-Data header), while the state maintained by these is > persistent. These are also not scoped per Chrome profile, unlike cookies. > So I'm not sure saying these must follow all cookie rules is accurate > here. I'd be more comfortable not overloading the cookie request header. > > > > *Sasha: I would consider them as 1st party cookies, as an IDP creates > cookie for itself. The cookie is created by > login.microsoftonline.com/live.com > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flogin.microsoftonline.com%2Flive.com&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716302589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=LBcXoEqGhLaMu%2F8ccQOuSWTd48zcjJSjf%2FMyfFXoqQo%3D&reserved=0> > for itself ( login.micosofotonline.com/live.com > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flogin.micosofotonline.com%2Flive.com&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716302589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=lmg3Acibyp68N4D9IqWLVQ9nyM2tikAt5a4rbUHd4dc%3D&reserved=0> > ), but outside of browser during windows logon/application logon. Clean all > the cookies will not actually clean them (they will be re-created), and yes > in this aspect it is auth **😊* > > > > *> Is there some other communication behind the scene between the OS and > the IDP here to authenticate the device? Or is this just a matter of > encoding data in the request?* > > > > I think it is easier to answer this question is to describe what cookie > is. Please, note, format of the cookie is something internal between IDP > native component and IDP web services. Microsoft’s cookie is JWT-blob that > contains PRT > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fdevices%2Fconcept-primary-refresh-token&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716458799%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=xc7TVluKdtKNOqU3FSwp8EjjGXxqojzY4%2FKTW4iQEJQ%3D&reserved=0>, > nonce, and signature. The PRT contains deviceid, userid and the key hash. > The key for the signature is in a hardware chip, e.g., TPM: > > > > { > > ctx: "HfRmDwiULBY5mDyUxd8\/RQV2xs72B55H", > > *alg*: "HS256" > > }. > > { > > request_nonce: "AQABAAAAA…. < used to make sure that issuer still has > access to the hardware key >", > > refresh_token: "AQABAAAAAAA….< an encrypted by IDP blob that contains > deviceid, userid, keyHash >", > > *iat*: *1597885901* > > }. > > [signature] > > > > When such cookie arrived to IDP, we check nonce and signature. It gives us > assurance PRT comes from the same device as it was originally created. > Hence, we can trust device and user info inside PRT. A browser doesn’t > create PRT, PRT is created and updated: > > 1. During Windows logon > 2. Application logon (if user has added account), e.g., when Outlook > accessing Exchange. > > > > Browser just reads PRT-cookie. > > > > Thank you, > > Aleksandr > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH0PR00MB1313E2E1FE66EEFFD8F75BAEA1649%40PH0PR00MB1313.namprd00.prod.outlook.com > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fchromium.org%2Fd%2Fmsgid%2Fblink-dev%2FPH0PR00MB1313E2E1FE66EEFFD8F75BAEA1649%2540PH0PR00MB1313.namprd00.prod.outlook.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716458799%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=BO6wyhW0%2BrsbbNXp5CtzL0Puxa8vrIuKt1Zb5zoF5iE%3D&reserved=0> > . > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEK7mvowd1TkNxhjWyCc4HQgLT9962WtVaWAWf8hZJP1MTkaaQ%40mail.gmail.com.
