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 > > > > 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 > > > > 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%7C7bba6f2c401c48b6c07508da7be61470%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958525391009574%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VxQQuuFWcv8RJzhi6Hpd75kAWJpblYkurSvnGd6Fi4U%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%7C7bba6f2c401c48b6c07508da7be61470%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958525391009574%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cHmg%2B6uLraGZf66dt7LoShnxiQQJ0Vk7RknUmgW%2Fxlk%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%7C7bba6f2c401c48b6c07508da7be61470%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958525391009574%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9CMQTZ9GTAAHF53x6gbsABrc40DzstVYIIFuTmPcr%2B4%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%7C7bba6f2c401c48b6c07508da7be61470%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958525391009574%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Vda4%2BLZo%2FYxh%2B1A5lctiBBBjrbYfJsWGvuvd2OlAASQ%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%7C7bba6f2c401c48b6c07508da7be61470%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958525391009574%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vj%2FcOYW43k748%2Bc1g2xPUbf%2BzphYfW6xtWgN1TVRli4%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%7C7bba6f2c401c48b6c07508da7be61470%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958525391009574%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RoNkLN2d%2Be11G1Scw0w9xyAsSj05U2i9ux32etcVciQ%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%7C7bba6f2c401c48b6c07508da7be61470%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958525391009574%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jLmXwZunJDvop0QJ%2FxP6gBl1xVvOO0C5LhdSbz68E2Y%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%7C7bba6f2c401c48b6c07508da7be61470%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958525391009574%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RoNkLN2d%2Be11G1Scw0w9xyAsSj05U2i9ux32etcVciQ%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%7C7bba6f2c401c48b6c07508da7be61470%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958525391009574%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EMvnB3YqVm22MppHIkX3DsP1Idpo5GtavR1QB9Jlm0c%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%7C7bba6f2c401c48b6c07508da7be61470%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958525391009574%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Lduk1pbbX8%2BZ6F7ucs%2B6f1Y2KsT0L6a6BFvipXwqKJM%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%7C7bba6f2c401c48b6c07508da7be61470%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958525391165793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tcZLjvbavAONIIsPQTGV7Jw822xAZtthVUAF9YxgsNE%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%7C7bba6f2c401c48b6c07508da7be61470%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958525391165793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3Wb5e2FQHE42rg4cOl82LYB6cacisuLTLRqXZybtabY%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%7C7bba6f2c401c48b6c07508da7be61470%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958525391165793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3Wb5e2FQHE42rg4cOl82LYB6cacisuLTLRqXZybtabY%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%7C7bba6f2c401c48b6c07508da7be61470%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958525391165793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3Wb5e2FQHE42rg4cOl82LYB6cacisuLTLRqXZybtabY%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%7C7bba6f2c401c48b6c07508da7be61470%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958525391165793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=u8t5TEvF6gUdgupjbOuElAfBOskIpLxcRMlKOXl3grI%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%7C7bba6f2c401c48b6c07508da7be61470%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958525391165793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=e8M2WP95%2BQQ%2BAy9NFVE1blKIZsZ0voP1%2BkrKBaSvB8w%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%7C7bba6f2c401c48b6c07508da7be61470%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958525391165793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yqtGnADxj%2BCKsiZshOwBP1xSa8DT17PFCJgB1WuJmdk%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%7C7bba6f2c401c48b6c07508da7be61470%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958525391165793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RmgCKm44kO2FpT913VZOTe0VW1NGFRkfpCvYkr6YZ7k%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://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH0PR00MB1313E2E1FE66EEFFD8F75BAEA1649%40PH0PR00MB1313.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer> > . > -- 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/CALhVsw3mYahmAnsadmi_Wg22aVPiVXNNZxJrUypvgKHsK69zrA%40mail.gmail.com.
