SAML login flow
An SP-initiated SAML login involves three steps:- Initiate — Your app asks the SDK to start the flow; it redirects the user to the Identity Provider.
- Callback — After authenticating, the IdP posts back and Prelude redirects to your app with a
challenge_token. - Finalize — Your app sends the
challenge_tokento complete authentication.
challenge_token is finalized exactly like social login — via finalizeOAuthLogin.
How is the SAML flow secured?
How is the SAML flow secured?
SP-initiated SAML is protected by PKCE (Proof Key for Code Exchange). The SDK generates a unique
code_verifier/code_challenge pair for each login and stores the verifier locally. The IdP’s SAMLResponse is matched against the AuthnRequest it answers (InResponseTo), and the challenge_token can only be finalized once, by the browser that started the flow.Redirect to the Identity Provider
There are two ways to start the flow.By connection
When you know the connection, pass itsproviderId and connectionId:
By email
To resolve the connection from the user’s email domain (it must match exactly one enabled connection’s allowlist), useloginWithSAMLByEmail:
redirectURI is optional — it must be allowlisted for your app, and falls back to the connection’s default_redirect_uri when omitted.
Both methods navigate the browser to the IdP. If you need the IdP URL without
navigating (e.g. to open it yourself), call
initiateSAMLLogin /
initiateSAMLLoginByEmail, which return { redirect_url }.Handle the callback
When the IdP redirects back to your app, extract thechallenge_token from the URL and finalize the login — the same call used for OAuth:
Try it
Try it
Replace
src/App.jsx with:src/App.jsx
What’s next?
If your application requires certain email domains to use SSO exclusively, see Enforce SSO login for handling thesaml_login_required fallback.