The difference between SP-Initiated and IdP-Initiated Single Sign-On (SSO)

Giving users efficient ways to access your platforms is what will boost sign-ups and increase engagement with your apps.

It’s no wonder many users are feeling a sense of ‘password fatigue’, with more and more sites demanding unique sets of login credentials. But there are plenty of alternative ways to simplify the signup process for users and increase the security of your platforms, too.

Single sign-on (SSO) is an increasingly popular approach, allowing users to access multiple sites with one set of login details. If you’re thinking about leveraging SSO in your app, it’s important to understand the different ways to initiate an SSO session and whether Service Provider (SP) or Identity Provider (IdP) initiated SSO is right for you.

When you’re designing your app’s user experience, you want to do everything you can to make signing up and signing in as easy as possible (without compromising a high level of security).

With single sign-on (SSO) you can achieve just that. This approach to authentication allows users to sign in once and gain access to multiple apps without needing to reauthenticate each time.

To make this happen, SSO uses a range of protocols including IdPs, SPs as well as Security Assertion Markup Language (SAML), OpenID Connect, and OAuth.

The obvious benefit of SSO is a fast-tracked log-in experience for users. Rather than logging into stacks of different apps individually, SSO means a user can enter their credentials once, and instantly gain access to other platforms and apps (such as using their Gmail logins to access the apps they need to do their job, such as Salesforces, Clickup, and Slack).

As a developer or founder, SSO offers a more secure login and sign-up experience, too. It lowers the chance of users setting weak or duplicated credentials and makes it easy for you to keep track of who is and isn’t an authorized user.

In Identity and Access Management (IAM), there are two important parties:

• Service providers (SPs): the entity that unlocks access to a service or resource, such as apps, websites, or APIs. This could include CRMs like Salesforce, Google Apps, Amazon Web Services (AWS), or even SaaS tools, like Slack.
• Identity providers (IdPs): the entity that grants access to resources through the authentication process. IdPs typically include platforms like Okta, Microsoft Azure Active Directory, or Google Cloud Identity.

Generally speaking, SPs are responsible for providing access whereas IdPs work to create, store and manage user identities.

These two parties work together to make user authentication and authorization happen across a range of different apps and platforms. Not only do SPs and IdPs ensure that the right user is gaining access to the right resources (with as minimal friction as possible), but they work together to lower the chance of security breaches and outsider attacks, too.

As the name suggests, SP-initiated SSO is kicked off on a service provider’s website. Typically, this happens when a user tries to access a protected page of an SP’s website or secure part of an app.

From here, the SP checks whether the user has been authenticated. If not, the user is redirected to the IdP’s login page and is asked to authenticate their identity. After the user enters their credentials successfully, the SP receives a message about what level of permissions the user has (a.k.a. What pages or resources they can access).

The SP then creates a session for the user, allowing them to access this app or resource. Now, this user has access to any other apps hosted by the same SP, without needing to reconfirm their identity or re-enter their login credentials.

On both the user and app side, there are stacks of benefits to using SP-initiated SSO, including:

• A smoother user experience, enabling users to authenticate once and access multiple apps without re-entering their login details.
• A robust approach to security, with users only entering one set of login credentials, rather than creating weak or replicated passwords across multiple sites. If these details are compromised, your app can become vulnerable to outside attackers or intruders.
• A simplified approach to access management, making it easy for companies to offboard employees and revoke access to all apps (without manually logging into multiple apps).
• A reduction in password-related IT requests can free up time and resources within your team.

Wondering if SP-initiated SSO is right for your company? Here are a few signs to look out for:

• Do you have multiple apps that need authentication? If your users need to gain access to a bunch of apps to perform their job, SP-initiated SSO can streamline the access process and save time for your team.
• Are you looking for a secure approach to authentication? Not only does this approach lower the chance of weak or duplicated passwords, but it can be integrated with multi-factor authentication (MFA) to further increase the security of your apps.
• Do you want to simplify user access management? If you’re running a growing company, it can become time-consuming and tedious to offboard employees from your systems. But with SP-initiated SSO, you can easily revoke access with just a few clicks.

On the flip side, IdP-initiated SSO is a process that starts with identity providers. This means a user first tries to authenticate with an IdP, which sends a SAML message to the SP to grant user access.

This typically happens when a user visits an IdP’s login page. Once authenticated, a SAML message is created that contains a user’s authentication status and attributes. This message is then sent over to the SP who is able to verify a user’s authentication status and grant access to specific pages or resources.

If your company has multiple SPs, this approach can be a helpful way to streamline access. This means your users only need to authenticate once with an IdP and gain access to all the SPs they need, without needing to reauthenticate their identity.

Initiating SSO through an IdP offers a range of benefits, including:

• A centralized authentication process for companies who a number of different SPs.
• A consistent login experience that allows users to enter their credentials once, rather than authenticating multiple times across each SP.
• An easy way to manage user accounts and handle access controls, with a streamlined way to revoke access when users offboard or leave a company.

Not sure whether IdP-initiated SSO is right for your company? Here are a few signs to look out for:

• Do you use multiple SPs? If so, it can be easier to ask users to log in through one IdP to simplify the user experience and streamline the login process.
• Do you want to offer the same login process across multiple SPs? Rather than sending users off to the login pages of each SP you use, this process allows users to verify their identity once and automatically gain access to multiple accounts across different SPs.
• Do you want to increase security in your company? By using IdP-initiated SSO along with MFA, you can use a combination of authentication factors (from possession to biometric factors) to grant users access and lower the chance of cyberattacks.

When it comes to selecting the right approach to SSO, it’s important to consider the kinds of platforms, apps, and services your company is using. If you’re using one SP, then SP-initiated SSO is likely to be the better choice. However, if you’re using multiple SPs, IdP-initiated SSO will help you simplify the login experience while safeguarding the security of your platforms, too.

See how Kinde compares to other authentication providers.