IdP-Initiated SSO

What is IdP-Initiated SSO?

IdP-Initiated SSO (Single Sign-On) is a login flow where the authentication process begins from the Identity Provider (IdP) rather than the Service Provider (SP). This is in contrast to SP-Initiated SSO, where the user starts at the SP and is redirected to the IdP for authentication.

How It Works:

1. A user directly accesses the IdP (e.g., Okta, Azure AD).
2. The user selects the application (SP) from a dashboard or app launcher.
3. The IdP authenticates the user and sends a SAML or OIDC response to the SP.
4. The SP validates the assertion and grants access.

IdP-Initiated SSO is commonly used in enterprise environments with centralized access portals.

Alternatives to IdP-Initiated SSO

1. SP-Initiated SSO

• The user accesses the application (SP) directly (starts from the application login page).
• The SP redirects the user to the IdP for authentication.
• After a successful login, the user is redirected back to the SP with a token or assertion.

SP-Initiated SSO is more common in B2C and SaaS scenarios where users typically start at the application URL.

Benefits of IdP-Initiated for Enterprises

• Centralized Access: Users log in once via a secure portal and access multiple apps.
• Improved UX: Simplified login experience with fewer redirects.
• Stronger Access Controls: Policies and multi-factor authentication (MFA) can be enforced centrally.
• Faster Onboarding: Users can access assigned apps immediately from the IdP dashboard.
• No SP Deep Linking Required: Works well for general app access without requiring deep link support in the SP.

How Descope Supports IdP-Initiated

Descope fully supports IdP-Initiated SSO workflows and provides robust, enterprise-grade tooling:

• SAML and OIDC Support: Compatible with leading IdPs like Okta, Azure AD, Google Workspace, and more.
• Secure Flow Handling: In Descope, IdP-Initiated SSO is handled securely by internally initiating an SP-Initiated flow after receiving the IdP request. This ensures consistent validation and reduces security risks.
• Inbound Federation Support: Configure Descope to accept IdP-initiated login flows using secure assertion validation.
• Attribute Mapping: Automatically map IdP attributes to Descope user profiles and roles.
• SSO JIT Provisioning Integration: Combine IdP-Initiated SSO with Just-in-Time provisioning for seamless account creation.
• RBAC & Custom Claims: Define roles and permissions based on IdP-provided claims.
• Audit Logging: Full visibility into IdP login events for security and compliance.

With Descope, you can easily enable IdP-initiated SSO across your applications while maintaining strong access control and user experience.

Implementing IdP-Initiated SSO with Descope Flows

To enable and handle IdP-Initiated SSO using Descope Flows in your application, follow the steps below:

1. Configure a Conditional Flow for IdP-Initiated Detection

Include a conditional check (such as an if/else branch) within your login flow that determines whether the Identity Provider initiated the authentication request.

• If the request is IdP-Initiated, the flow should automatically log the user into the application.
• If not, the flow should continue to display the standard login screen, allowing the user to authenticate via an SP-Initiated flow.

This flow condition ensures the flow supports both IdP and SP-Initiated SSO scenarios seamlessly.

2. Set the Post Authentication Redirect URL

The Post Authentication Redirect URL must point to a page in your application configured to handle the IdP-Initiated condition, as described in the step above.

You can configure this URL at:

• The project level, in the SSO Auth Method settings page.
  • Dynamic URL values are also supported if you use different domains per tenant or customer.
• The tenant level is within the tenant’s SSO configuration page.

IdP-Initiated SSO with Descope SDKs

When using the Descope SDKs to support IdP-Initiated authentication:

• The redirect URL should lead to a page that can capture the code parameter from the URL.
• Your application must then exchange the SAML code via the Descope SDK to complete the authentication process.

Refer to the client, mobile, or backend specific SDK documentation for details on how to perform this token/code exchange.