---
title: Login Flows
description: Learn the differences between SP‑initiated and IdP‑initiated SSO.
originalPath: .tmp-workos-clone/packages/docs/content/sso/login-flows.mdx
---
The instructions in the [Quick Start guide](/sso) focus on setting up Service Provider (SP)-initiated SSO. In these scenarios, when a user attempts to login, they navigate to an application (a service provider) and are then redirected to the [Identity Provider (IdP)](/glossary/idp) for authentication, via the WorkOS API.
Alternatively, most users are able to start the process from the Identity Provider itself. Organizations will often provide an IdP dashboard where employees can select any of the eligible applications that they can access via the IdP, similar to the screenshot below. Clicking on a tile results in an IdP-initiated login flow, since the user initiates the login from the Identity Provider, not the application.
---
## SP-initiated SSO
With an SP-initiated login flow, the user begins the authentication process from your application. You can control where the user will be redirected after login by specifying the `redirectURI` parameter when making the [Get Authorization URL](/reference/sso/get-authorization-url) call. Additionally, this call can take an optional `state` parameter - this parameter will be returned in the callback after authentication, where your application can use it to verify the validity of the response or to pass any state from the originating session. One common practice is to route requests from different Organizations to a single Redirect URI, but instead utilize the `state` parameter to deep link users into the application after the authentication is completed.
---
## IdP-initiated SSO
If you follow the instructions in the [Quick Start guide](/sso), IdP-initiated login flows will automatically be available, and users will be able to find a tile for your application within their IdP, similar to the screenshot above. Clicking on the tile will send an IdP-initiated SSO response to your application's callback endpoint.
### Configure IdP-initiated SSO
Additionally, since IdP-initiated flows do not generate a customized authorization URL the way SP-initiated flows do, there is no way to dynamically pass the `redirectURI` and `state` parameters to your application's callback. By default, users will be redirected to the default Redirect URI upon a successful login. However, IdP Administrators can customize the redirect destination by configuring a default `RelayState` in the IdP, and including a `redirect_uri` parameter in it. The URI must be specified in the format of a URL parameter: `redirect_uri=uri`, and the URI must be one of the Redirect URIs specified in your WorkOS [Dashboard](https://dashboard.workos.com). Any other values in the IdP’s `RelayState` will be ignored and discarded.
Your application will also be able to retrieve the [Profile object](/reference/sso/profile) for the user upon successful authentication. If your IdP is unable to provide a `redirect_uri` in its default `RelayState`, or if you would like to generate a custom redirect URI for each user after they sign in, you can use the [Profile object](/reference/sso/profile) to dynamically generate a redirect URI.
```json title="Example Profile"
{
"id": "prof_01DMC79VCBZ0NY2099737PSVF1",
"connection_id": "conn_01E4ZCR3C56J083X43JQXF3JK5",
"connection_type": "okta",
"email": "todd@example.com",
"first_name": "Todd",
"idp_id": "00u1a0ufowBJlzPlk357",
"last_name": "Rundgren",
"object": "profile",
"custom_attributes": {}
}
```
The Profile object includes the `connection_id` which identifies the connection that the profile is associated with in WorkOS. We recommend using the connection information for routing requests in an IdP-Initiated flow.
### Disable IdP-initiated SSO (Beta)
We have recently added Beta support for fully disabling IdP-initiated SSO logins for a connection. Once disabled, any attempted IdP-initiated requests will fail with an `idp_initiated_sso_disabled` error.
> Disabling IdP-initiated SSO is currently in invite-only beta, please reach out to [WorkOS support](mailto:support@workos.com) if you’d like to use it or learn more about it.
For applications that need to support IdP-initiated workflows, but would like to mitigate the security risks of unsolicited SAML responses, WorkOS recommends the following:
- Disable IdP-initiated SSO for your connection.
- Adjust your callback method to capture the `idp_initiated_sso_disabled` error.
- Start a new SP-initiated request from the callback when the error is detected.
The error callback will include the connection and organization ID’s, which can be used to request a new authorization URL for the SP-initiated request. The new request will generally be transparent to the user, as they are already logged in to the Identity Provider.
## Implementing SSO with WorkOS
This document offers guidance to integrate Single Sign-On with our standalone API into your existing auth stack. You might also want to look at [AuthKit](/authkit), a complete authentication platform that leverages Single Sign-On functionality out of the box, following best practices.