What Is Single Sign-On (SSO) and How Does It Work?

What is Single Sign-On (SSO) and How Does it Work?

Single sign-on (SSO) is a critical part of almost every organization’s strategy for user management and authentication. Learn about the benefits of SSO, how it works, and what it takes to implement SSO in your organization.

What Is SSO (Single Sign-On)?

Single Sign-On (SSO) is a protocol used to authenticate and authorize users to multiple applications using a single set of credentials. SSO is very convenient for users because they don’t need to memorize multiple passwords and don’t need to perform multiple login operations. When implemented correctly, Single Sign-On (SSO) solutions also improve security and reduce risks created by weak, repeated, or lost passwords.

Modern identity and access management (IAM) solutions can help enterprises implement SSO for multiple applications under their control. Open standards like OAuth 2.0 and OIDC can help users authenticate for applications via any identity provider, even external to the organization. Modern SSO leverages social login, where users can access applications using their existing credentials for services like Google, Facebook, or Twitter.

If you are building a new application or a cloud-based system, SSO should be an important consideration. SSO dramatically simplifies usage and improves the user experience. Even more importantly, it enhances security by standardizing authentication and giving users only one password instead of several. 

This is part of an extensive series of guides about Access Management.

In this article:

9 Benefits of SSO

The key benefits of single sign-on are:

  1. Reduced Password fatigue: This is achieved by reducing the need to remember different usernames and passwords.
  2. Faster logins: Users can log in faster thanks to the reduced times needed to re-enter passwords whenever the same user logs in.
  3. Less Third-party risk: SSO mitigates risks associated with accessing third-party websites (i.e., federated authentication) and avoiding the external storage and management of user passwords.
  4. Lowered IT costs: There is a big drop in the number of password reset and signing in calls to the IT help desk, thus lowering costs.
  5. Simple admin: SSO processes are transparent and involve the same tools used for other admin tasks. 
  6. Added Control: All network management data is in one repository, providing a unified source to control user privileges. Admins can easily modify access privileges throughout the network. 
  7. More Productivity: Users avoid disruptions and delays due to multiple logins or managing multiple passwords. They can access protected network areas easily and get back to work immediately. 
  8. Better Network security: Complex password management is a common cause of security breaches because users often write down the passwords. By consolidating the network access data, admins can confidently disable user accounts. 
  9. Network consolidation: Admins can connect separate networks to consolidate their management efforts and oversee all diverse, distributed environments. 

Types of SSO

When identifying and operating SSO, you need to be aware of the different protocols and standards. These include:

Security Access Markup Language (SAML)

SAML is an open standard for encoding text into machine language and exchanging identifying information. It has become one of the core standards for SSO and is used by many application providers to validate authentication requests. SAML 2.0 is optimized for web applications and can send information through a web browser.

Open Authorization (OAuth)

OAuth is an open standard authentication protocol that encrypts identity information and transmits it securely between applications. This allows users to access data from other applications without having to manually verify their identity. This is especially useful for native mobile applications.

OpenID Connect (OIDC)

OIDC is an extension of OAuth 2.0, which adds information about users and enables SSO. This allows multiple applications to use one login session. For example, users can log into a service using their Facebook or Google account instead of entering their credentials.


Kerberos is a ticket-granting protocol that allows mutual authentication, enabling a user and a server to authenticate each other over an insecure network connection. It is commonly used for authentication in Windows environments and for software applications like email clients.

Physical token authentication

In addition to traditional SSO, many organizations use physical tokens to allow users to securely connect to applications. The token typically requires the user to input a PIN, to enable two-factor authentication. Software on the computer interacts with the encryption key on the smart card to authenticate the user. Smart cards are considered very secure, but they can still be obtained by attackers (for example, if the user loses the card), and are expensive to deploy.

Learn more about SSO providers that implement one or more of these standards:

How Does Single Sign-on Work?

To make SSO possible, an identity provider (IdP) must provide a central authentication server, which multiple applications can use to verify user identities. The authentication server validates user identities and confirms their identity to the application by providing an encrypted access token.

When a user first logs into an application, they are redirected to the IdP and are asked to provide their credentials, typically username and password. 

For example, when signing in to Asana, users can use two different identity providers to login: Asana user name or Google. When users select one of the options, they are redirected to the relevant IdP to perform authentication.


The authentication server checks the user’s credentials against its central user directory, and if they are valid, starts an SSO session. Subsequently, the user can access the application for a predetermined period without logging in again. 

When the user attempts to access another application from the trusted group, there is no need to request credentials again. The application requests authentication from the IdP, leveraging the open SSO session. The IdP provides an access token, and the application grants access to the user without showing the login screen again. 

Here is an example of an SSO workflow:

  1. The user requests a resource from their desired application/website.
  2. The application/website redirects the user to the Identity Provider for authentication, using SAML, OpenID Connect, etc.
  3. The IdP authenticates the user and passes a token to the SSO server.
  4. The SSO server delivers the token to the application.
  5. The application grants access to the user.

Now, the user can access all other applications which are configured for SSO. If the user wants to access a resource from another application, that application checks if they have an active SSO session, and if so, uses the same token to grant access.

How Secure Is SSO?

Single sign-on is not a perfect solution for all use cases. Some SSO implementation challenges include managing costs, standardization (OAuth or SAML), control, and security. Authentication vulnerabilities (i.e., the “Sign In with Apple” and Microsoft OAuth flaws) allow attackers to sign into a web service or site, posing as the target user. 

It’s also important to consider how SSO platforms integrate into an organization’s overall IT architecture. Organizations must carefully configure their SSO solutions to maintain their security posture. In some cases, SSO systems block the ability of security solutions to detect a user’s origin IP address when attempting to log in to the system. 

On the other hand, single sign-on can provide stronger security than some alternatives used to control access to an organization’s services. For example, some companies require users to keep separate logins for each service, introducing other security issues. 

SSO helps reduce the IT infrastructure’s attack surface. Users don’t have to remember multiple passwords, and they don’t have to enter credentials several times a day. The centralized admin approach allows administrators to implement stronger security measures like MFA and good password practices. SSO does not make the infrastructure less secure and often helps increase security.

Implementing SSO In 5 Steps

SSO implementation revolves around a central server. All applications trust this master server and use it to access login credentials. If your organization has multiple applications, they probably run on different servers, using different user directories and authentication mechanisms. For single sign-on to work, you must integrate all your applications with the central SSO server. 

Follow these steps to implement SSO authentication in your organization.

1. Map Out The Applications You Want to Connect to SSO

Identify which applications should be part of your SSO structure. Look at user login patterns and identify which users need to access which applications. Create SSO “bundles” for each set of applications commonly accessed by a group of users. See if your SSO solution has built-in integrations with them. If not, prepare development resources to build an integration. 

2. Integrate With Identity Provider (IdP)

If you have your own identity provider, ensure the SSO solution can integrate and test the integration. Determine the protocol you will use to connect to the IdP, typically Security Assertion Markup Language (SAML). Otherwise, see which external IdPs your SSO solution supports—social login via platforms like Google or Facebook is commonly used and is convenient for most users. 

3. Verify The Data in Your Identity Directory

For SSO to work, you must have accurate, authoritative information about your users. It is also critical for identities in your IdP to match up with identities used in applications connected via SSO. Ensure that each user in your user database has an up-to-date email and credentials. The data verification process is also an opportunity to remove old users and revoke unnecessary privileges.

4. Evaluate User Privileges

Before implementing SSO, carefully evaluate which users or roles have access to which applications. Most organizations adopt the least-privilege principle, where each user receives the minimal privileges they need to perform their function. Ensure you define privileges carefully, based on a solid understanding of the business uses of each application.

5. Ensure The SSO System is Highly Available Secure

SSO is a mission-critical service and a single point of failure for your applications. If you are running the SSO server on-premises, you must set up redundancy and ensure the server has appropriate network and application layer security controls. If you are using a cloud service, see what reliability or availability tiers it offers, and select the most suitable for your organization. Ensure you have correctly configured the provider’s security options.

Learn more in our guides about: 

SSO Deep Dive: Understanding Common SSO Protocols

SAML and WS-Federation

Security Assertion Markup Language (SAML) and Web Services Federation (WS-Fed) are common options for implementing SSO. These protocols use XML files to exchange data about the user, the IdP, and the application (known as the service provider).

Connection Flow

  1. A user requests to access a resource in an application (service provider) that participates in SSO
  2. The application checks with the IdP to see if the user is permitted to access the required resource.
  3. The IdP authenticates the user, and if the user has access, returns an assertion that the user should be able to access the resource.

SAML Use Cases

  • Using SAML for SSO—SAML can enable SSO transactions. A SAML service can provide requests to access secure resources, including an authentication element and attributes providing data about the user.
  • Using SAML for ACL—SAML can be used to enforce access control lists (ACL). SAML can support ACL transactions, in which a user requests to access a secure resource, and the SAML service provides an authorization decision. This use case typically does not include authentication.

OpenID Connect

OpenID Connect (OIDC) is an authentication and authorization protocol used for customer-facing single sign-on, based on the OAuth 2.0 authorization standard. OIDC performs authentication using JSON Web Tokens (JWT) and integrates with one or more identity providers.

Connection Flow

  1. A user requests access to an application.
  2. The application redirects the request to the identity provider.
  3. The IdP authenticates the user. If authentication is successful, the IdP displays a prompt asking the user to grant access to the required application.
  4. The IdP generates an ID Token with identity information that the application can use.
  5. The IdP redirects the user back to the application, and the user can access it without providing credentials again.

OpenID Connect Use Cases

OIDC supports both secure authentication and authorization, as well as API access. There are three main flows you can use for different use cases:

  • Implicit—mainly used for single-page applications. Tokens are granted directly to the application (relying party) via a redirect.
  • Authorization Code—mainly used for native apps, single-page apps, and mobile web apps. This flow is suitable for applications that cannot be trusted to store sensitive data. This flow enables the use of cryptographically-signed JWT tokens and does not share user data with the application.
  • Hybrid – This approach combines the two aforementioned flows. At first, it returns an ID token to the application via redirect URI. Then, the application submits the ID Token and receives a temporary access token.

Related content: JWT authentication


The Lightweight Directory Access Protocol (LDAP) is an application protocol that provides access to a directory of credentials. It exchanges information using the LDAP Data Interchange Format (LDIF). You can share an LDAP directory across multiple applications. 

When you use LDAP with Active Directory (AD), you can store user identities in the central AD server, and applications make authentication requests to the LDAP/AD server. 

Connection Flow

  1. The application (known as the client) sends a request to access information stored in an LDAP database.
  2. The application provides user credentials (username and password) to the LDAP server
  3. The LDAP server matches user-submitted credentials with user identity data stored in the LDAP database or AD. User identities can be based on attributes like addresses, phone numbers, or group membership.
  4. If the provided credentials match the stored user ID, LDAP permits the client to access the requested information.
  5. If the credentials are incorrect, LDAP denies access.

LDAP/AD Use Cases

Because LDAP is an open, cross-platform protocol, you can use it with multiple directory service providers and applications. LDAP is most commonly used as a central location to store credentials like usernames and passwords.

Popular applications that support LDAP authentication include OpenVPN, Docker, Jenkins, and Kubernetes. System administrators can use LDAP’s SSO feature to manage LDAP database access across multiple applications.

Social Login vs. Enterprise SSO

Many popular social media services, including Google, LinkedIn, Twitter, and Facebook, provide SSO services. These services allow end-users to log into third-party applications using their social media authentication credentials. While social single sign-on is convenient for users, it can also pose a security risk, by creating a single point of failure that attackers can exploit.

Many security experts say that social login is not appropriate for enterprise access control, because if an attacker compromises the user’s social credentials, they can use those credentials to access multiple organizational systems. 

Enterprise SSO is a single sign-on solution that gives end users secure one-click access to all enterprise applications, validating users against a trusted identity provider controlled by the organization. This allows the organization to implement more stringent measures to prevent identity theft. For added security, businesses can also implement multi factor authentication (MFA) or adaptive MFA.

SSO with Frontegg 

Once you integrate Frontegg’s self-served user management solution, your customers can configure their SSO completely on their own with just a few lines of code. The single sign-on can be integrated with IDPs with commonly-used protocols like OIDC and SAML.

Yes, you can implement social login SSOs as well. The front end has been taken care of as well. You can leverage all of Frontegg’s SSO components and personalize your SaaS offering with a login box builder. This embeddable box reduces implementation times as no in-house development is required. Users can authenticate smoothly and gain quick access to the app, without waiting for product updates and fixes.

A true end-to-end SSO solution for SaaS apps and services.

See Additional Guides on Key Access Management Topics

Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of access management.

User Management

Authored by Frontegg


Authored by Frontegg

Network Topology Mapping

Authored by Faddom

Looking to take your User Management to the next level?

Sign up. It's free