Introduction to Single Sign-on

Single Sign-On (SSO) streamlines user access by enabling a single authentication event to grant access to multiple applications with the same credentials. For example, logging into one Google service, such as Gmail, automatically authenticates you to YouTube, Google Drive, and other Google platforms.

There are two key benefits to the users and organizations with a secure single sign-on implementation:

1. User can seamlessly access multiple applications using only one set of credentials.
2. User credentials are managed in a centralized identity system. This enables Admins to easily configure and manage authentication policies for all their users from the centralized identity provider.

Furthermore, this integrated SSO mechanism enhances user convenience, boosts productivity, and reduces the risks associated with password fatigue and reuse. These security & administration benefits are driving factors for enterprise organizations to only procure SaaS applications that offer SSO-based authentication.

How Single Sign-On (SSO) works

Fundamentally, Single Sign-on works by exchanging user information in a pre-determined format between two trusted parties - your application and your customer's identity provider (aka IdP). Most of these interactions happen in the browser context as some steps need user intervention.

To ensure secure exchange of user information between your application and your customer's identity provider, most IdPs support two protocols: Secure Assertion Markup Language (SAML) or OpenID Connect (OIDC). The objective of both these protocols is same: allow secure user information exchange between the Service Provider (your application) and Identity Provider (your customer's identity system). These protocols differ in how these systems trust each other, communicate, and exchange user information.

Let's understand these protocols at a high level.

SAML

SAML 2.0 (Secure Assertion Markup Language) has been in use since 2005 and is also most widely implemented protocol. SAML exchanges user information using XML files via HTTPS or SOAP. But, before the user information is exchanged between the two parties, they need to establish the trust between them. Trust is established by exchanging information about each other as part of SAML configuration parameters like Assetion Consumer Service URL (ACS URL), Entity ID, X.509 Certificates, etc.

After the trust has been established, subsequent user information can be exchanged in two ways -

1. your application requesting for a user's information - this is Service Provider initiated login flow
2. Or the identity provider directly shares user details via a pre-configured ACS URL - this is Identity Provider initiated Login flow

Lets understand these two SSO flows.

Service Provider initiated SSO

SP initiated SSO workflow

For service provider initiated SSO flow,

1. User tries to access your application and your app identifies that the user's credentials need to be verified by their identity provider.
2. Your application requests the identity provider for the user's information.
3. The identity provider authenticates the user and returns user details as "assertions" to your application.
4. You validate assertions, retrieve the user information, and if everything checks, allow the user to successfully login yo your application.

As you can imagine, in this workflow, the user login behaviour starts from your application and thats why this is termed as service provider initiated SSO (aka SP-initiated SSO)

Identity Provider initiated SSO

IdP initiated SSO workflow

In case of Identity Provider initiated SSO,

1. User logs into their identity provider portal and selects your application from within the IdP portal.
2. Identity Provider sends the user details as assertions to your application.
3. You validate assertions, retrieve the user information, and if everything checks, allow the user to successfully login yo your application.

Since the user login workflow starts from the Identity Provider portal (and not from your application), this flow is called as Identity Provider initiated SSO (aka IdP-initiated SSO).

Risks with IdP initiated SSO

IdP initiated SSO is susceptible for common security attacks like Man In the Middle attack, Stolen Assertion attack or Assertion Replay attack etc. Read the IdP initiated SSO guide to understand these risks and how to mitigate them.

OIDC

OpenID Connect (OIDC) is an authentication protocol based on top of OAuth 2.0 to simplify the user information exchange process between Relying Party (your application) and the OpenID Provider (your customer's Identity Provider). The OIDC protocol exchanges user information via signed JSON Web Tokens (JWT) over HTTPS. Because of the simplified nature of handling JWTs, it is often used in modern web applications, native desktop clients and mobile applications. With the latest extensions to the OIDC procotol like Proof Key of Code Exchange (PKCE) and Demonstrating Proof of Possession (DPoP), the overall security of user exchange information is strengthened.

In it's current format, OIDC only supports SP initiated Login. In this flow:

1. User tries to access your application. You identify that this users credentials need to be verified by their Identity Provider.
2. Your application requests the user's Identity Provider for the user's information via an OAuth2 request.
3. Identity Provider authenticates the user and sends the users details with an authorization_code to a pre-registered redirect_url on your server.
4. You will exchange the code for the actual user details by providing your information with the Identity provider.
5. Identity Provider will then send the user information in the form of JWTs. You retrieve the user information from those assertions and if everything is valid, you will allow the user inside your application.

How does Scalekit help

Scalekit serves as an intermediary, abstracting the complexities involved in handling SSO with SAML and OIDC protocols. By integrating with Scalekit in just a few lines of code, your application can connect with numerous IdPs efficiently, ensuring security and compliance.

Explore our Quick Start guide to integrate your application with Scalekit in just a few steps, leveraging our robust SSO solution.