IdP-initiated SSO: How to turn a dashboard tile click into a normal sign-in

IdP-initiated SSO for SAML begins when an employee clicks an application tile in their identity provider’s dashboard, unlike SP-initiated flows that begin within the application and offer stronger control over request validation and session handling. WorkOS recommends configuring an application sign-in endpoint so that, after a tile click, it redirects the user to that endpoint with a connection_id; the application then initiates a normal authorization request and processes the usual callback, reducing the security concerns associated with unsolicited SAML responses. The endpoint should pass the connection ID to WorkOS’s authorization URL method, while ordinary application-initiated sign-ins can continue using their existing organization or connection selection logic. Callback handling remains unchanged, but applications should validate the returned profile’s organization ID against their own records rather than relying on email domains. Without a sign-in endpoint, WorkOS sends the authorization code directly to the default redirect URI, requiring the application to identify the tenant only after exchanging the code and reading the profile’s connection information. Customers can use SAML RelayState with a client_id to target a particular application in environments containing multiple WorkOS applications. Implementations should be tested through a real IdP tile, monitored through WorkOS session records or authentication events, and checked for redirect URI configuration, since misconfigured endpoints can cause sessions to time out.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.