SSO Authentication: Workflows, Protocols, and Implementation

Authentication

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

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

If you are building a new application or a cloud-based system, Single Sign-On 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 multiple ones. Let’s learn more about this popular authentication methodology.

How Does Single Sign-On Work?

To make SSO possible, the identity provider (IdP) must provide a central authentication server, which multiple apps can use to verify user identities. This server validates user identities and confirms their identity by providing an encrypted access token. When users first log into an app, they are redirected to the IdP and asked to provide their credentials (username, password). 

For example, when signing in to Spotify, users can use three different identity providers to login: Facebook, Apple, or Google. When users select one of the options, they are redirected to the relevant IdP to perform authentication.

Courtesy: Spotify

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. 

SSO Authentication

The Single Sign-On Workflow

In a typical SSO architecture, identity providers and service providers exchange digital certificates and metadata to establish trust. They interact through open protocols such as Security Assertion Markup Language (SAML), OAuth, and OpenID (discussed in more detail below).

When integrating SSO platforms into the IT architecture of your organization, carefully consider existing security mechanisms. For example, in an SSO system, downstream security tools may not detect the source IP address of a user trying to log into the system. To avoid breaking other access control and alerting systems, ensure that security tools are still able to identify the user.

Here is a practical example of a SSO workflow:

  1. The user requests a resource from their desired application or website.
  2. The application or 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 that 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.

SSO Protocols

Let’s take a look at the main SSO protocols in use today.

SAML

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

Connection Flow

  1. The user requests to access a resource in an application (service provider) that participates in the SSO flow.
  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 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 app 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 apps 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 – Combines the 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: JWT Authentication

LDAP/AD

Lightweight Directory Access Protocol (LDAP) is a 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 apps.  When you use LDAP with Active Directory (AD), you can store user identities in the central AD server, and apps 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 app 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

LDAP is an open and cross-platform protocol that can be used with multiple directory service providers. It’s most commonly used as a central location to store credentials like usernames and passwords. Popular apps that support LDAP authentication include OpenVPN, Docker, Jenkins, and Kubernetes. Admins can use LDAP’s SSO feature to manage LDAP database access across multiple apps.

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 ecosystem. Look at user login patterns and identify which users need to access specific applications. Create SSO “bundles” for each set of applications that are commonly accessed by groups of users. See if your SSO solution has built-in integrations with them, and 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 High SSO System Availability

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

SSO Authentication with Frontegg

Frontegg provides secured SSO authentication with multiple SSO protocols such as SAML, OIDC, and OAuth. The authentication platform available for the Frontegg customers is leveraging each of these protocols to allow customers to safely login their users into their products with zero effort and no prior protocol knowledge. Sounds too good to be true? Well it’s not. Check it out now.

GET SSO

Subscribe
Notify of
guest
Conversations(0)
Inline Feedbacks
View all comments