Why single sign-on (SSO) is better

Single sign-on (SSO) is a technology that allows users to authenticate once and access multiple applications. If you only have one application, it may sound like overkill. However, starting with SSO from the beginning can save you a lot of headaches down the road, and implementing SSO is easier than you think.

Before we get started, we need to note that there are two types of SSO:

• The first type is when you have multiple applications that share the same user database. This is the type of SSO we will be discussing in this article.
• The second type is when your client has a centralized identity provider (IdP) and you need to integrate with it. This is out of scope for this article.

Why SSO?

Simplify the authentication model

The most obvious benefit of SSO is that it simplifies the authentication model. Imagine you start with an online store, the initial authentication model is straightforward:

As your business grows, you decide to add a store management app to allow store owners to manage their stores. Now you have two applications that need to authenticate users.

Here are some choices you have:

1. You can create a separate user database for the store management app.

This is the simplest solution, but it means that you need to implement the authentication process for the store management app and users have to create a new account to use the app.

2. You can use the same user database for both applications.

This is a better solution because users don't need to create a new account. However, you still need to implement the authentication process for the store management app.

3. You can use SSO.

This is the best solution so far. You don't need to implement another authentication process and users don't need to create a new account for the store management app. Furthermore, you can add more applications and sign-in methods without changing the authentication model or user experience.

Improve user experience

SSO improves the user experience in two ways:

• Users can share the same account across multiple applications.
• Once users sign in in one application, they don't need to sign in again in other applications on the same device.

Some concerns may arise here, but they are all addressable.

1. How to differentiate applications?

Single sign-on doesn't mean that we treat all applications the same. In the well-known open standard OpenID Connect, each application is called a client, and the authentication flows differ depending on the client type. While the end users don't need to know the difference, the client type is important for the authentication server to determine the authentication flow.

2. What if users don't want to share the same account?

This is a valid concern, but it's not a problem with SSO. If users don't want to share the same account, they can create a new account for the new application. The key is to give users the option to choose.

3. What if I need to restrict access to certain applications?

In fact, SSO is a technique for authentication, while access control is for authorization. SSO can be decoupled from access control. For example, you can use SSO to authenticate users, then use role-based access control (RBAC) to restrict access to certain applications or resources.

To learn more about authentication and authorization, check out CIAM 101: Authentication, Identity, SSO.

4. SSO requires redirecting users to the authentication server.

Redirecting is a standard practice for authentication. Considering the user experience, we can leverage multiple techniques to reduce the friction:

• Use refresh tokens to reduce the frequency of authentication.
• Initialize the authentication process with a specific sign-in method, such as Google or Facebook, to reduce the number of clicks.
• Leverage silent authentication to speed up the authentication process.

Enhance security

1. A central place for all security-related operations

SSO allows you to manage all security-related operations in a central place. For example, as we mentioned in the previous section, SSO can still differentiate applications and apply platform-specific authentication flows for each application. Without SSO, you need to implement various authentication flows according to the application type.

In addition, advanced security features such as multi-factor authentication (MFA) are easier to implement with SSO without messing up the authentication model.

2. Reduced attack surface

In theory, SSO reduces the attack surface because you only need to secure one authentication server instead of multiple applications. The centralized approach also makes it easier to monitor and detect suspicious activities.

3. Battle-tested standards and protocols

Open standards and protocols such as OpenID Connect and OAuth 2.0 are widely used in the industry and have been battle-tested for years. Both of them match the concept of SSO and are supported by most identity providers (IdPs). By combining these standards with SSO, you can have a secure and reliable authentication system.

OK, let's implement SSO

Implementing SSO can be big and complicated, there are many things to consider, such as:

• Compliance with standards and protocols
• Authentication flows for different client types
• Multiple sign-in methods
• Security features such as MFA
• User experience
• Access control

Each of these topics can be a separate article and overwhelming. For the sack of simplicity, it's better to start with a managed service that provides SSO out of the box. Our product Logto is such a service, and it will only take you a few minutes to integrate it into your application.

One of the most common concerns of using a managed service is vendor lock-in. Fortunately, this is not an issue with Logto. Logto is built on top of OpenID Connect and OAuth 2.0, and it's born open-source. We prioritize providing assurance to our customers and aim to empower you with the freedom to choose.