Hey, We have an issue that when a customer logs in via SSO it requires him to login three times before it "catches". Did anyone experience something similar?

Hi, I'm Descope's AI assistant. I've put together an initial response below based on your question. A member of the support team will take over and follow up shortly. Issue Description We have an issue where a customer logging in via SSO is required to log in three times before it successfully connects. Has anyone experienced something similar? Possible Causes • Configuration issues with the SSO setup. • Network latency or connectivity problems. • Session management issues on the client or server side. Next Steps 1. Verify the SSO configuration settings to ensure they are correct. 2. Check for any network issues that might be causing delays. 3. Review session management logs for any anomalies. Conclusion If the problem persists after these checks, please escalate the issue to the support team for further investigation.

I don't see any issues, and it happens for one customer

@Reuven Zabirov please check this out. @Meir Armon what is the identity provider?

@Doron Sharon it's Entra

What is the project id and tenant id?

Project ID - Peuc12xdTvhV8KS3Fr6spmV71aLvL7GN Tenant ID - f044077a-4bdc-4394-a7af-9891bf3cf0c5

Got it, I can see this is an IdP-initiated login. For additional security, when we receive an IdP-initiated login, we internally convert it into an SP-initiated and redirect back to the IdP. With most IdPs this is seamless because the session is already stored at the IdP side, so the user doesn’t notice anything. However, with Microsoft Entra, depending on their configuration, the session isn’t always persisted, which can cause the user to see the login prompt again (sometimes multiple times, depends on their configuration). We have a feature flag that allows skipping this SP-initiated validation step specifically for such cases. We can enable it for your project if you’d like.

What are the drawbacks for enabling it? Are there negative effects?

IdP initiated are less secure by definition, because the authentication is not initiated by the application itself, so the app has less control over validating the request context/state. That’s exactly why we convert IdP initiated logins into SP-initiated ones, it allows us to enforce additional validations. Disabling this, just reduced security hardening since we rely on the IdP assertion as is. But, it’s still considered acceptable, especially if the IdP/SP are well-configured (short lived assertions, proper signing, etc.) So as always, it is trade off between security and UX.

Sounds reasonable. Can we enable this for project ID Peuc132onXAjytu2gaj0g8xhf1iCvSkl first, and after we test internally we'll enable for the second project?

yes

🙏

Done

Seems to work 🔥 Can you please enable the FF on Peuc12xdTvhV8KS3Fr6spmV71aLvL7GN as well?

yes

Thank you 🙂 Please let me know when it was done 🙏

Done