In SAML, there is IdP-initiated and SP-initiated login. IdP-initiated login ends up posting an unsolicited SAMLResponse to the SP, which has known security disadvantages. However, what if SP-initiated login is triggered from the IdP using a start login URL?

  • The SP has a start login URL. Visiting this URL starts SP-initiated SAML login.
    • Crucially, at this point the SP can first generate a RequestId and RelayState, securely store them, and then redirect to the IdP. This allows the SP to eventually validate the SAML response by checking its InResponseTo (expected to contain the RequestId) and RelayState against the previously stored values.
  • An administrator configures the IdP with this SP's start login URL.
  • When an end user wants to initiate a login into the SP from the IdP, the IdP redirects the user to the SP start login URL, which then proceeds with SP-initiated SAML login by redirecting the user back to the IdP.

This setup allows the end user to start the SAML login at the IdP, but still have security benefits of SP-initiated SAML login.

Aside: A parallel with "IdP-initiated" login in OpenID Connect

Since OIDC has does not support IdP-initiated login the way SAML does (with an unsolicited response) the recommended way to set up IdP-initiated login in OIDC is described in this Auth0 excerpt:

OpenID Connect (OIDC) does not support the concept of an IdP-Initiated flow. So while Auth0 offers the possibility of translating a SAML IdP-Initiated flow (from a SAML connection) into an OIDC response for an application, any application that properly implements the OIDC/OAuth2 protocol will reject an unrequested response.

When using OIDC applications, the best option is to have your application create a login endpoint. This endpoint’s sole purpose is to initiate the redirect back to the IdP (your Auth0 tenant).

Source: https://auth0.com/docs/authenticate/protocols/saml/saml-sso-integrations/identity-provider-initiated-single-sign-on#openid-connect-idp-initiated-flow

That's exactly what the setup in the previous section does, except with SAML.

Aside: Microsoft Entra is an example IdP which supports the approach outlined above

When configuring a Microsoft Entra application as a SAML IdP, the administrator has the option to configure start login URL which, as stated, can be used for SP-initiated login:

Microsoft Entra SP-initiated login


What do you call this setup in SAML? It's clearly not IdP-initiated SAML, since that refers to the SP receiving an unsolicited SAMLResponse. It's also not quite SP-initiated SAML, since that implies the user initiated the login from the SP (e.g., through a login screen at the SP).

For context, if there is a specific term for this, I intend to use it when making a feature request to Okta, which currently only supports traditional IdP-initiated SAML login.

  • 1
    It's still SP-initiated. The fact that user went somewhere that redirected them to SP is outside of the SAML spec. The SAML-specified sequence starts at SP. Start/login/launch URLs have been around forever, they're the UX equivalent of syntactic sugar.
    – identigral
    Commented May 30 at 21:04

1 Answer 1


It's not the same as the Entra implementation, but you can get a similar effect in Okta by hiding the icon for your SAML app then creating a bookmark app with the sign in URL for the SP. Users will use the bookmark, get redirected to the SP, which will redirect them back to Okta.


  • Good to know about this Okta workaround; thank you! I'll keep the question as unanswered for now in the hopes of getting clarity on what this "SP-initiated SAML triggered by the IdP" flow is called.
    – mxxk
    Commented May 23 at 21:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .