Enterprise SSO authentication flows

There are two types of Enterprise SSO connections: EASIE and SAML.

EASIE

EASIE connections support the authentication flows described at easie.dev.

SAML

The SAML protocol supports two methods to start an SSO flow: Service Provider-initiated (SP-initiated) and Identity Provider-initiated (IdP-initiated).

For the best security practices, it's recommended to use the SP-initiated flow wherever possible. If you decide to enable IdP-initiated flows, ensure that proper security measures, such as MFA and short validation periods, are in place to mitigate the associated risks.

Service Provider-initiated flow (recommended)

In an SP-initiated flow:

• The user starts the authentication process from your application (Service Provider, or SP), by providing their email address.
• The user is redirected to the SAML provider (Identity Provider, or IdP) where they must authenticate.
• After successful authentication, the user is redirected back to your app, gaining access to their account.

Identity Provider-initiated flow

In an IdP-initiated flow:

• The user starts the authentication flow from the SAML provider (IdP) by selecting which app (SP) they want to access.
• The user is redirected to the app of their choice, gaining access to their account.

To allow IdP-initiated flows for your SAML connection:

1. In the Clerk Dashboard, navigate to the SSO connections page.
2. Select Add connection and select For specific domains.
3. Select your Identity Provider. Complete the fields and select Add connection. You'll be redirected to the SAML connection's configuration page.
4. Select the Advanced tab.
5. In Advanced Settings, enable Allow IdP-Initiated flow. A modal will open. Select Enable to confirm.
6. Select Save.

Risks of IdP-initiated flow

While IdP-initiated flows might offer convenience, they are also susceptible to security risks, such as meddler-in-the-middle (MITM) attacks. A bad actor might hijack the IdP response to gain access to a compromised account.

When enabling an IdP-initiated flow, it's possible for Clerk to receive unsolicited authentication requests, which neither the SP nor IdP can verify were initiated by the specified user. Additionally, a bad actor could intercept the IdP response and replace it, performing a CSRF attack to sign in as the attacker.

Clerk's security measures

To mitigate the risks associated with IdP-initiated flows, Clerk implements several security measures:

• Unsolicited InResponseTo attribute: Clerk ensures that unsolicited responses don't contain an InResponseTo attribute, in accordance with the SAML 2.0 profiles specification. This prevents bad actors from stealing a response used in an SP-initiated flow and using it in an IdP-initiated flow.
• Replay detection: Clerk consumes and remembers each response to prevent re-use. This ensures that bad actors cannot steal and reuse a response to gain access to a user's account.
• Multi-factor authentication: Clerk supports multi-factor authentication (MFA) for SAML IdP-initiated flows. MFA requires users to provide two or more forms of verification, which significantly enhances security by reducing the risk of unauthorized access.
• Use small validation periods: Each SAML response contains a timestamp indicating when it was issued and when it will expire. Since IdP-initiated flows are expected to be completed within seconds, validation periods must be as small as possible to prevent attacks. Common IdP providers such as Azure, Google, and Okta handle this by default. However, if you're using a custom IdP, you must ensure that the validation periods are set correctly.