IdP-initiated SSO vs SP-initiated SSO

Terminology#

• Identity Provider (IdP): The service that stores and authenticates user identities.
• Service Provider (SP): A web or service that provides services to users.
• Single Sign-On (SSO): A session and user authentication service that permits a user to use one set of login credentials (e.g., name and password) to access multiple applications.
• SAML: Security Assertion Markup Language is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. It is a commonly used protocol for SSO. Once a user is successfully authenticated by the IdP, the IdP sends a SAML assertion to the SP, which the SP validates and grants access to the user.
• OIDC: OpenID Connect is an more modern and secure protocol for SSO. It is built on top of OAuth 2.0 and provides a way to verify the identity of the user based on the authentication performed by the IdP. Once a user is successfully authenticated by the IdP, the IdP sends an JWT formatted token to the SP, which the SP validates and grants access to the user.

What is SP-initiated SSO?#

As the name suggests, SP-initiated SSO is initiated by the service provider. The user starts the authentication process by accessing a resource on the SP's website. The SP then redirects the user to the IdP for authentication. Once the user is authenticated, the IdP generates a token (OIDC) or a SAML assertion (SAML) and sends it back to the SP. The SP validates the token or assertion and grants access to the user.

1. User visits the SP's website and tries to access a resource.
2. User click on the SSO provider's login button (e.g. Google, Azure AD, Okta, etc).
3. SP redirects the user to the IdP for authentication.
4. User logs in to the IdP.
5. IdP sends a token or assertion back to the SP.
6. SP validates the token or assertion and grants access to the user.

What is IdP-initiated SSO?#

Unlike SP-initiated SSO, IdP-initiated SSO is initiated by the identity provider. The user starts the authentication process from the IdP's website. Normally, the user will find a list of supported SP applications on the IdP's portal. The user clicks on the SP application and redirects to the SP's website with a pre-authenticated identity.

1. User logs in to the IdP.
2. User visits the IdP's portal and selects an SP application.
3. IdP validates the user's current session and redirects the user to the SP with a pre-authenticated SSO identity.
4. SP validates the SSO identity and grants access to the user.

Idp-initiated SSO vs SP-initiated SSO#

Advantages of IdP-initiated SSO#

IdP-initiated SSO in more adopted by large enterprise and organizations that rely on various third-party apps or services. Like Workday, Salesforce etc. It provides a centralized way to manage user access to multiple applications and enforce SSO authentications. By enabling IdP-initiated SSO, employees can directly access the connected applications from the IdP's portal without the need to visit each application's website. Reducing the onboarding time and improving the user experience.

Disadvantages of IdP-initiated SSO#

IdP-initiated SSO carries more risk compared to SP-initiated SSO:

1. Lack of authentication context: All the authentication requests initiated from IdP are unsolicited. Thus, the SP initiated the authentication process, potentially opening the door to unauthorized access. There is a risk that the user's session could be hijacked. A malicious actor could initiated the login process for a legitimate user without their knowledge or consent.

2. Session fixation: Since the SP does not initiate the authentication process, the user's session could be fixed to the IdP's session. This could lead to session fixation attacks where an attacker could fix the user's session to the IdP's session and gain unauthorized access to the user's account.

3. Phishing attacks: IdP-initiated SSO could be vulnerable to phishing attacks. A malicious actor could trick the user into visiting a fake IdP's portal and steal the user's credentials. Once the user logs in, the attacker could redirect the user to the SP with a pre-authenticated identity.

4. No assurance on request validation: In a SP-initiated SSO, normally the SP will includes necessary security information in the request to the IdP to maintain the integrity of the request. Once the SP receives the authentication response, it will validate these information to prevent any CSRF attacks. E.g. The state parameter in OIDC and RelayState in SAML. However, in IdP-initiated SSO, the SP does not initiate the authentication process, thus the SP has no assurance on the request validation.

Limitations of IdP-initiated SSO:

IdP-initiated SSO is not supported by OIDC due to the above vulnerabilities. OIDC requires the SP to initiate the authentication process to ensure the validity of the request. Even is cases where users begin the authentication process from a third-party that is not the SP, the user should be first directed to the SP to initiate the authentication process.

IdP-initiated SSO is more common in SAML based SSO. The IdP can generate a SAML assertion w/o the SP initiating the authentication process. In a SAML IdP-initiated SSO, a SAML assertion without a proper RequestID and RelayState could be sent to the SP's ACS URL directly. The SP should be able to handle this kind of assertion and grant access to the user. (Note: Without the RequestID and RelayState, the SP has no assurance on the validity of the request).

Advantages of SP-initiated SSO#

In all aspects, SP-initiated SSO is considered more secure and reliable compared to the IdP-initiated SSO. No matter the protocol (OIDC or SAML), it ensures that the authentication process is tied to an active user session and a specific request initiated by the SP. This reduces the risk of certain attacks, such as Replay Attacks and Identity Confusion, by providing the following security benefits:

1. Contextual binding to the SP: In SP-initiated SSO, the authentication process starts with the SP, which establishes the context of the request. This ensures the user is being authenticated specifically for the SP they are interacting with, reducing the risk of misdirected assertions.
2. Reduced risks of unsolicited requests: SP-initiated SSO helps prevent attackers from injecting or misusing authentication tokens or SAML assertions, as the SP explicitly requests the authentication from the IdP, validating it against the session state.
3. Stronger session management: SP-initiated flows allow the SP to have greater control over session creation and validation, enabling better session management and security enforcement at the SP level.

Disadvantages of SP-initiated SSO#

Even though SP-initiated SSO is more secure and is highly recommended in all scenarios, due to the business requirements and the limitations of the third-party applications, IdP-initiated SSO is still in use in many organizations.

• User experience: SP-initiated SSO requires the user to visit the SP's website to start the authentication process. This can be cumbersome for users who want to access multiple applications from the IdP's portal. Especially for those enterprise only SaaS applications that are more commonly accessed from the IdP's portal.
• Complexity: SP-initiated SSO requires additional configurations at the SP side to handle the authentication requests. This can be complex to set up and maintain. For legacy systems, it may take extra effort to integrate SP-initiated SSO.

Conclusion#

Both IdP-initiated SSO and SP-initiated SSO have their use cases, but SP-initiated SSO is strongly recommended in today’s world, where data privacy and cybersecurity are more important than ever. It offers better security by ensuring authentication requests are tied to the Service Provider’s session, reducing risks of unsolicited requests and providing stronger session management. However, IdP-initiated SSO is still necessary for broader adoption and ease of access, especially in environments where user convenience and centralized access are priorities.

Try Logto today. With the Logto SSO solution, you can easily integrate both IdP-initiated and SP-initiated SSO for your applications and gradually migrate to a more secure and reliable authentication system.