SP-Initiated vs. IdP-Initiated Authentication Flows


























Two Types of Identity Flows When Using an Identity Provider (IdP)

In modern identity management, especially in cloud and enterprise environments, understanding how authentication flows work is critical. Whether you’re managing internal employees or external users, there are two main types of identity flows you’ll encounter when working with an Identity Provider (IdP): SP-Initiated and IdP-Initiated authentication flows.

Let’s break them down.

SP-Initiated (App-Initiated) Flow

In a Service Provider (SP) Initiated flow, the user begins their journey by visiting the application first — not the IdP.

For example, if you go directly to dash.cloudflare.com and click “Sign In,” the application (Cloudflare) will redirect you to your configured IdP (like Okta or EntraID) to authenticate. After successful authentication, you’re sent back to the app.

Key Point: You start at the app — not at the IdP portal.

Flowchart: SP-Initiated Authentication

SP-Initiated Flowchart

IdP-Initiated Flow

In an IdP-Initiated flow, the user begins at the Identity Provider’s portal, where all the registered applications are listed.

Think of an Okta Portal or an EntraID MyApps page — users log in to their IdP dashboard, see all their authorized apps, and click to launch them from there. The authentication handshake happens behind the scenes.

Key Point: You start at the IdP portal — you don’t navigate to the app directly.

Flowchart: IdP-Initiated Authentication

IdP-Initiated Flowchart

Employee-Focused vs End User-Focused Identity Systems

  • Employee-Focused Systems: Systems like Okta, Microsoft EntraID (formerly Azure AD), or traditional On-Premises Active Directory (AD) typically store and manage employee identities.
  • End User-Focused Systems: Systems like Azure B2C Tenants are designed to manage customer or external user identities rather than internal employees.

This distinction is important because the IdP infrastructure and flow requirements differ significantly between workforce and consumer scenarios.

Key Roles and Concepts

  • Service Provider (SP): The application itself — examples include Cloudflare, ServiceNow, and countless SaaS platforms. SPs trust your IdP to assert your identity.
  • Source of Truth: In most enterprises, the On-Prem Active Directory remains the primary authoritative source for identity data. Identities are synchronized outward to cloud IdPs like EntraID and Okta.

Real-World Observations

  • Companies can (and often do) use multiple IdPs. Different apps might be integrated with different providers — some apps authenticate via Okta, others via EntraID.
  • MFA (Multi-Factor Authentication) methods vary by IdP:
    • For EntraID, MFA typically uses the Microsoft Authenticator app.
    • For Okta, MFA typically uses the Okta Verify app on your mobile device.

In Summary

When planning your identity strategy, you need to know:

  • How users will access apps (SP-Initiated vs. IdP-Initiated)
  • Whether you’re managing employees or external customers
  • Which IdP(s) you’re using — and how they integrate with your Source of Truth
  • How MFA is handled across your identity landscape

A well-architected identity flow ensures seamless access, high security, and a smooth user experience across all your applications.