How Does Single Sign-On Work?

Single Sign-On (SSO) is an authentication technique that enables users to access multiple applications with a single login. This is performed via a central authentication server that maintains and verifies the user’s credentials for each application.

The concept of SSO is not new in the Cloud era. This technology is derived from on-premises identity solutions that allowed businesses to securely connect their PCs, networks, and servers in the mid to late 1990s. Around this time, companies began to employ specialised systems to manage user IDs, such as Lightweight Directory Access Protocol (LDAP) and Microsoft Active Directory. Following that, they deployed on-premises SSO or Web Access Management (WAM) systems to secure access.

Table of Contents

How Does SSO Work?

It works by building a trust relationship between an application (known as the service provider) and an identity provider (such as OneLogin). This trust relationship is frequently built around a certificate exchanged between the identity supplier and the service provider. This certificate can be used to sign identity information transmitted from the identity provider to the service provider, ensuring that it comes from a trusted source. In SSO, this identification data comes in the form of tokens, which contain identifying information about the user, such as an email address or a username.

What is an SSO Token?

An SSO token is a collection of data or information that is transferred between systems as part of the SSO procedure. The data can be as simple as a user’s email address and the system from which the token is sent. Tokens must be digitally signed in order for the token receiver to verify that it is from a trustworthy source. The certificate required for this digital signature is transferred during the initial configuration process.

Three important participants in the SSO game are:

Identity Provider (IdP): The core authentication server is this one. You submit your credentials there to get validated. See it as the entrance to a very secure building.
Service Provider (SP): SSO is required for user login in each of these distinct applications. The CRM platform, project management tool, and work email can all be SPs. Consider these as personal offices inside the safe structure.
SSO Server: From the IdP to the SPs, this is the bridge. Ensuring the security of authentication token transfers and handling communication is handled by it. Consider it a safe passageway that links the main door to the other departments.

The SSO workflow

Services like Google are great example of how SSO functions. Consider attempting to use your Google account to access Notion. It is not necessary to register for a new Notion user account and keep track of new usernames and passwords.

For instance, Notion connects you to the central service housed on accounts.google.com when you attempt to log in using your Google account. You’ll find a sign-in form to enter your credentials here. If the authentication process is successful, Google will take you to Notion, where you will already be signed in.

Single Sign-On — _{Accessing Notion via a Google account}

The procedures to use your Google account to access Notion are as follows:

User requests access: Use the Notion login web page and select Google account as a login method.
Redirection to IdP: Notion redirects the user to the Google login page.
Login page served: The user is served with the Google login page.
Credentials entered: The user enters their Google credentials.
SSO Server verification: Google sends authentication info to the SSO Authorization server
Authentication at IdP: The Authorization server returns the auth token (SAML) if the credentials are valid.
Access granted: Google sends the auth token to the Notion
Validate token: In the last step, Notion sends the token to the Google Authorization server to validate it
Token valid: If the token is valid, Notion will allow access to the user and store the session for future interactions

The login flow typically looks like this:

A user navigates to the Service Provider, often known as the application or website, to gain access.
As part of a request to authenticate the user, the Service Provider sends a token to the SSO system, also known as the Identity Provider, that contains some information about the user, such as their email address.
Initially, the Identity Provider determines if the user has already undergone authentication. If so, it will allow the user to access the Service Provider application and move on to step 5.
The user will be asked to log in by entering the Identity Provider’s needed credentials if they haven’t already. This could be as simple as a username and password, or it could have an additional authentication method, such as an OTP (one-time password).
A token verifying a successful authentication will be sent back to the Service Provider by the Identity Provider after it has verified the credentials submitted.
The Service Provider receives this token via the user’s browser.
The trust connection established between the Service Provider and the Identity Provider during the initial configuration is used to validate the token that the Service Provider receives.
The Service Provider grants the user access.

A identical trust relationship set up with the SSO solution would need to be followed by the new website when the user tries to access it, and the authentication process would need to occur in the same order.

Is single sign-on secure?

The answer to this issue is, “It depends.”

There are numerous reasons why SSO can enhance security. A single-sign-on solution can make username and password administration easier for both users and administrators. Users no longer need to keep track of many sets of credentials and may instead remember a single, more difficult password. SSO typically allows users to gain access to their applications much faster.

SSO can also reduce the amount of time the help desk spends serving users who have lost their passwords. Administrators can centrally manage requirements such as password complexity and multi-factor authentication (MFA). Administrators can also more swiftly remove all login credentials when a user quits the organisation.

Single Sign-On has various downsides. For example, you may want to increase the level of security for some applications. For this reason, it is critical to select an SSO solution that allows you to, for example, need an additional authentication factor before a user logs into a certain application or bans users from accessing certain applications unless they are connected to a secure network.

Advantages of SSO

There are several advantages to SSO, including:

Improved user experience: It is not necessary for users to remember several usernames and passwords.
Increased security: Passwords are not as frequently used by users across different apps.
Simplified user access auditing: Ensuring sensitive data and resources are accessible to the right people can be difficult. According to a user’s role, department, and seniority level, SSO solutions can customise their access permissions.

Disadvantages of SSO

Moreover, the SSO has a few significant drawbacks:

Single point of failure: Establishing a single point of failure is one of the most prominent drawbacks of SSO. If the SSO system is hacked, the attacker may be able to access all linked apps and facilities.
Security risks: The security of any connected application may be risked if credentials are stolen.
App compatibility: Sometimes an application isn’t set up properly to integrate with an SSO system. Applications that use OAuth, SAML, or Kerberos should be able to execute real SSO. If not, users will have one more password to remember and your SSO solution won’t provide full coverage.

Types of SSO

Working with SSO requires familiarity with several standards and protocols. Several typical kinds of procedures include:

SAML: This is the most common form of SSO. It employs the SAML protocol to send authentication information between the SSO server and the applications.
Open Authorization (OAuth) 2.0): It grants authorised access to server resources on behalf of the resource owner. It specifies how tokens are exchanged, allowing an IDP to validate a user’s identity and provide credentials for API access.
Open ID Connect (OIDC) is a newer version of SSO that utilises OAuth 2.0. Compared to SAML, this protocol is easier to integrate with online applications.

Selecting the appropriate SSO protocol

When picking the correct protocol, one should consider the following:

Enterprise vs. consumer applications: SAML is often preferred for enterprise applications due to its extensive support and integration capabilities with enterprise identity providers and complex authentication scenarios. OAuth 2.0 and OIDC are more suited for consumer-facing applications, offering flexibility and compatibility with mobile and web applications.
Authorization vs. authentication: If your primary need is authentication (verifying user identity), SAML or OIDC are your go-to options. OIDC, built on top of OAuth 2.0, provides an additional identity layer over OAuth’s authorization capabilities. Use OAuth 2.0 when your application needs to request access to user resources without exposing user passwords.
Evaluate application and platform compatibility: Check the SSO protocols’ compatibility with your existing infrastructure and the applications you plan to integrate. Some legacy or enterprise systems might support SAML more broadly, while modern applications often favor OAuth 2.0 and OIDC because they are API-friendly.
Consider the user experience: OIDC and OAuth 2.0’s modern, token-based approach can offer a smoother and more integrated user experience, especially for web and mobile applications.
Future-proofing: Consider the future direction of your application ecosystem. Are you moving towards cloud-based services, APIs, and mobile apps? OAuth 2.0 and OIDC may offer more flexibility and are generally considered more forward-looking in cloud and mobile services.
Compliance and regulatory requirements: Ensure the chosen protocol meets any specific regulatory requirements relevant to your industry, such as GDPR, HIPAA, or others that may dictate specific security or privacy standards.

SSO implementations

There are numerous products on the market that can be utilised for SSO:

Microsoft Entra ID (formerly known as a Microsoft Active Directory). It is ideal for organisations that have already invested in the Microsoft ecosystem, as it seamlessly integrates with Office 365, Dynamics CRM, and other Microsoft services. It is well-known for its advanced security features and comprehensive administration capabilities.
Okta is a popular cloud-based SSO solution known for its ease of use, scalability, and wide range of application integrations.It’s an excellent choice for organisations looking for a comprehensive identity and access management (IAM) platform.
Ping Identity. Known for its flexibility, Ping Identity caters to enterprises with complex security requirements. It provides robust mobile and API security options, making it ideal for organisations that want high levels of customisation and protection.
OneLogin. With a focus on simplicity and integration, OneLogin offers a straightforward SSO solution that works well for small to medium-sized businesses. It offers real-time threat detection and AI-powered authentication to improve security.
Auth0 is favored for its developer-friendly approach. It provides powerful customization options, making it a go-to for organizations that must tailor their authentication flows. It supports a wide range of programming languages and frameworks.