SSO (Single Sign-On) explained.

SSO can be thought of as a master key to open all different locks. It allows a user to log in to different systems using a single set of credentials.

In a time where we are accessing more applications than ever before, this is a big help to mitigate password fatigue and streamlines user experience.

To fully understand the SSO process, let’s take a look at how a user would log into LinkedIn using Google as the identity provider:

User requests access

First, the user would attempt to access the Service Provider (LinkedIn). At this point, a user would be presented with login options, and in this example, they would select “Sign in with Google”.

Authentication request

From here, the Service Provider (LinkedIn) will redirect the user to the Identity Provider (Google) with an authentication request.

IdP checks for active session

Once the Identity Provider (Google) has received the request, it will check for an active session. If it doesn’t find one, authentication will be requested.

User submits credentials

At this stage, the user will submit their login credentials (username and password) to the Identity Provider (IdP).

IdP verifies credentials

The Identity Provider will then verify the submitted credentials against its User Directory (database). If the credentials are correct, the IdP will create an authentication token or assertion.

IdP sends token to Service Provider

Once the token or assertion has been created, the IdP sends it back to the Service Provider confirming the user’s identity. The user is now authenticated and can access the Service Provier (LinkedIn).

Access granted using existing session

Since the Identity Provider has established a session, when the user goes to access a different Service Provider (eg; GitHub), they won’t need to re-enter their credentials. Future service providers will request authentication from the Identity Provider, recognize the existing session, and grant access to the user based on the previously authenticated session.

SSO workflows like the above operate on SSO protocols, which are a set of rules that govern how the IdP and SP communicate and trust each other. Common protocols include Security Assertion Markup Language (SAML), OpenID Connect, and OAuth.