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<mailto: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<mailto:mme...@chromium.org> Sent: Wednesday, July 20, 2022 8:52 AM To: blink-dev <blink-dev@chromium.org<mailto:blink-dev@chromium.org>> Cc: Sasha Tokarev <alex...@microsoft.com<mailto:alex...@microsoft.com>>; Owen Min <z...@chromium.org<mailto:z...@chromium.org>>; blink-dev <blink-dev@chromium.org<mailto:blink-dev@chromium.org>>; Greg Thompson <g...@chromium.org<mailto:g...@chromium.org>>; Ryan Sleevi <rsle...@chromium.org<mailto:rsle...@chromium.org>>; Adam Langley <a...@chromium.org<mailto:a...@chromium.org>>; Matt Menke <mme...@chromium.org<mailto: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<mailto:mme...@chromium.org>> Cc: Owen Min <z...@chromium.org<mailto:z...@chromium.org>>; blink-dev <blink-dev@chromium.org<mailto:blink-dev@chromium.org>>; Greg Thompson <g...@chromium.org<mailto:g...@chromium.org>>; Ryan Sleevi <rsle...@chromium.org<mailto:rsle...@chromium.org>>; Adam Langley <a...@chromium.org<mailto: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<mailto:mme...@chromium.org>> Sent: Saturday, September 25, 2021 7:45 PM To: Sasha Tokarev <alex...@microsoft.com<mailto:alex...@microsoft.com>> Cc: Owen Min <z...@chromium.org<mailto:z...@chromium.org>>; blink-dev <blink-dev@chromium.org<mailto:blink-dev@chromium.org>>; Greg Thompson <g...@chromium.org<mailto:g...@chromium.org>>; Ryan Sleevi <rsle...@chromium.org<mailto:rsle...@chromium.org>>; Adam Langley <a...@chromium.org<mailto: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<mailto: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: [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: [https://groups.google.com/u/1/a/chromium.org/group/blink-dev/attach/f938daf5806bc/image002.png?part=0.2&view=1] 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.
