Hello everyone, We’re implementing an OAuth login flow (with Microsoft) and facing a challenge with the SameSite attribute for our session cookies. Our preferred security setting is SameSite=Strict, but this causes issues post-authentication: users aren’t properly redirected back to our site, as the strict policy prevents our session cookies from being set upon return from Microsoft’s authentication page. Switching to SameSite=Lax resolves this redirection issue, but we’re concerned about the security implications. We want to ensure top security without compromising the OAuth functionality. Questions: 1. Is SameSite=Lax the only practical solution in such OAuth scenarios, or are there secure workarounds that allow us to keep SameSite=Strict? 2. If Lax is necessary, what additional security measures should we consider to mitigate any risks introduced by not using Strict? We’re looking for insights or best practices on balancing security with functional OAuth flows. Thanks in advance!

As far as I can tell, if you control the top level domain, Lax isn't at all concerning additional security configs that can provide confidence in the deployment include "allowed origins", "allowed headers", "allowed credentials"; so basically all the things CORS related and not necessarily Ory thing

Thanks for the CORS suggestions. We’ve temporarily disabled CORS for our investigation. Quick update: 1. With SameSite=Strict: Works seamlessly when I’m already signed into Microsoft in the browser. 2. Without Pre-logged Microsoft Account: The SameSite=Strict setting poses challenges. If I’m not signed in, it triggers the Microsoft sign-in dialog (+ MFA). Post-authentication, there’s a hitch with the session cookie transfer during the redirect back to ORY Kratos. It seems the extra redirects hinder the session cookie from being included in this process. Has anyone faced similar issues or have insights on this? Would love to hear. 🙂