Single Sign-On (SSO) Basics

With a standard app-specific authentication, each app in an ecosystem will have its own login and its own authentication process. This might be tedious because the user will have to authenticate multiple times. SSO, however, allows a user to go through the authentication process once and remain authenticated for all apps within an ecosystem.

How SSO works

Here's how SSO typically works:

1. The user requests access: When a user attempts to access an application or service that is part of an SSO-enabled system, they are redirected to a central authentication service.

2. The request is redirected to IdP: The request is redirected to the authentication service that validates the user's identity. This service is often called the identity provider (IdP), which maintains user account information and authentication credentials.

3. The user is authenticated: The user provides their credentials (username and password) to the IdP, which verifies these credentials against its stored records or other authentication mechanisms like multi-factor authentication (MFA).

4. Tokens are issued: Upon successful authentication, the IdP generates tokens that represent the user's authenticated session. Here are the two most common types of tokens are:

   1. Access token: This token contains information about the user's identity and permissions. It's used by the user to gain access to the different applications within the SSO ecosystem.

   2. Refresh token: This token is used to obtain a new access token without requiring the user to log in again. It helps maintain the user's session without needing frequent reauthentication.

5. The application is accessed: The user is redirected back to the original application with the access token. The application may include this token in the header of subsequent requests to verify the user's identity and permissions.

6. The access is validated: The application, known as the service provider (SP), may also communicate with the IdP to validate the authenticity and permissions associated with the token. This can involve sending the token to the IdP for verification.

7. The user signs off: When the user logs out of the application or their session expires, the user is logged out from all the applications connected to the SSO system. This ensures a consistent user experience across applications.

The following diagram outlines this process:

While the user is authenticated, the token issued by the service provider stays on the user's device or in the user's browser. This means that if there is another application connected to the same ecosystem and the same IdP, the user will not have to reauthenticate while accessing that application. However, if the user decides to log out, the session is likewise terminated for all applications.

Benefits of using SSO

The key benefits of using SSO are as follows:

• User convenience: Users only need to remember one set of credentials and can access multiple services seamlessly.

• Security: Centralized authentication reduces the risk of password fatigue, where users might reuse passwords across different applications.

• Centralized management: IT administrators can manage user accounts and permissions from a central location, simplifying user provisioning and de-provisioning.

• Audit trail: A central point of authentication provides better visibility into user activities across different applications.

Disadvantages of using SSO

While SSO offers numerous advantages, it also has disadvantages and potential challenges. Here are the main disadvantages of SSO:

• Single point of failure: The central authentication service or identity provider (IdP) becomes a single point of failure. If the IdP experiences downtime or a security breach, it can impact access to all connected applications, causing widespread disruption.

• Security risks: SSO introduces a potential security risk. If an attacker gains access to a user's SSO credentials, they can potentially access multiple applications. This makes securing the SSO system and implementing strong authentication methods (like multi-factor authentication) crucial.

• Complex implementation: Setting up and maintaining an SSO infrastructure can be complex and require significant effort, especially for large organizations. It involves integrating various applications and services with the IdP, which might not always be straightforward.

• Interoperability challenges: Different applications and services might use different authentication protocols or standards, making it challenging to achieve seamless interoperability across all of them.

• Vendor lock-in: Some SSO solutions might tie an organization to a specific vendor or technology stack, making it difficult to switch to another solution in the future.

• User privacy concerns: Centralized authentication means that the IdP has access to a significant amount of user data and activity across various applications. This can raise privacy concerns, especially if not handled properly.

• User experience issues: If the SSO system experiences downtime or performance issues, users might be unable to access any of the connected applications. This can lead to frustration and productivity losses.

• Limited offline access: SSO systems typically require an active internet connection to authenticate users against the IdP. This can be problematic if users need to access applications while offline.

• Legacy application compatibility: Older or legacy applications might not support modern SSO protocols, making it challenging to integrate them into the SSO ecosystem without custom development work.

• Lack of control: Organizations might have less control over the authentication process in an SSO environment compared to individual application-specific authentication. This can lead to a lack of flexibility in implementing security measures specific to each application.

• Implementation and maintenance costs: While SSO can save time and effort in the long run, the initial implementation and ongoing maintenance can be costly, requiring investment in infrastructure, integration, and training.

• User resistance: Users might be hesitant to adopt new authentication methods or worried about the security implications of using a single set of credentials across multiple services.

To mitigate these disadvantages, organizations must carefully assess their needs, choose a suitable SSO solution, implement robust security measures, and regularly monitor and update their SSO infrastructure to avoid potential security threats and challenges.

Also, some of the abovementioned issues are fully mitigated if the SSO configuration relies on standard protocols, like OpenID Connect and OAuth. For example, these eliminate vendor lock-ins and interoperability issues.

Well-known SSO examples

Two popular examples of SSOs that most people came across are the "Continue with Google" or "Continue with Facebook" prompts present on various websites. Here is how they might look like:

In this case, Google, Facebook, and Apple act as IdPs. When we select one of these options, we are redirected to the authentication page of the selected provider, such as Google. Typically, we are then either asked to log in if we aren't logged in already or confirm that we want to allow a token to be issued to access a specific website.

Because the authentication happens on the IdP website, the original website we want to access will not know our password. However, it will still be able to validate the token issued by the IdP to confirm a successful authentication.