How does Single Sign On work?

Using Single Sign-on (SSO) simplifies user logging in, allows better account management, and reduces user issues. But how does it work? This article provides all the answers and shows you how SSO functions.

Single sign-on (SSO) is an authentication procedure that permits users to access several applications with a single login credential. This simplifies your web experience by granting access to various web applications without the need to input your username and password repeatedly. Recognizing the innate vulnerabilities of passwords, the concept of SSO has evolved into what is now termed reduced sign-on (RSO). This transition is driven by adopting multiple authentication methods tailored to the risk profiles inherent in different enterprise environments. For example, in an SSO software enterprise, users log on with their ID and password. This process gives them access to low-risk information and multiple applications like the enterprise portal. However, when the user tries to access higher-risk applications and information, like a payroll system, the software requires them to use a more potent form of authentication. These forms of authentication may include digital certificates, security tokens, smart cards, biometrics, or combinations.

The internet is stateless. The SSO systems must constantly check whenever you try to access a web page or click on a different URL if there is an authentication policy on the webpage or URL you’re trying to access. This back-and-forth communication can cause traffic spikes between the user’s browser, the application server, and security servers, especially in big organizations with many users and resources. Hence, modern SSO systems store authentication and permission policies in Lightweight Directory Access Protocol (LDAP) directories. LDAP directories are designed for high-performance lookups, which address large traffic loads. Additionally, the system frequently uses LDAP directories for authentication.

Advantages of Single Sign-on

These are the benefits SSO provides:

• Reduced password fatigue: SSO reduces the risks of combining short and feeble passwords and usernames. It also reduces the time spent for re-entering passwords for the same identity.

• Reduced IT costs due to reduced help desk calls: IT costs were reduced due to a decreased number of IT help desk calls about passwords. Analyst Gartner specifies in a report that only 20 to 50 percent of help desk inquiries in IT are associated with forgotten passwords or password resets. Many SSO solutions permit users to reset passwords, often with help desk support.

• Better management control: All network management data are kept in a single repository. This ensures a singular, authoritative record of users’ permissions and entitlements. Consequently, administrators can confidently modify a user’s privileges, knowing that these adjustments will be applied consistently throughout the entire network.

• Improved user productivity: Users are relieved from recalling multiple passwords to access network resources.

• Simpler administration: Tasks are seamlessly integrated into routine maintenance, utilizing the same tools for other administrative duties.

Security Risks of Single Sign-on

Conversely, SSO may only be ideal for some use cases. Some thorny issues include managing costs, control and security, etc. It can also be a single point of failure.

The Achilles heel of this authentication procedure is that users’ credentials are vulnerable to compromise. An attacker can access all or most of the resources and applications on the network. Authentication exposures such as “Sign In with Apple” and Microsoft OAuth flaws allow attackers to pose as target users and sign into a site or web service.

As a countermeasure, the majority of security professionals recommend the incorporation of two-factor authentication (2FA) or multifactor authentication (MFA) into any single sign-on setup. 2FA or MFA requires users to provide at least one authentication element alongside a password, such as a code delivered to a mobile device, a fingerprint, or an ID card. Because hackers do not easily pilfer these supplementary credentials, implementing MFA can significantly reduce the risks associated with compromised credentials in SSO.

In addition, requiring users to set long and complex passwords and rigorously encrypting and securing those passwords wherever they are stored helps prevent hackers from gaining access.

Types of Single Sign-on

It’s essential to understand some standard SSO protocols. A few examples of these protocols are:

• Security Assertion Markup Language (SAML): SAML is a basic SSO protocol. It is an open standard that exchanges authentication and authorization information between different parties, specifically between an identity provider and a service provider. It has now become an indispensable standard and is adopted by numerous application providers to verify authentication requests.

• Open Authorization(OAuth): OAuth delegates access by enabling internet users to authorize websites or applications to access their information or data on platforms without disclosing their passwords.

• OpenID Connect (OIDC): OpenID connect is an open authentication protocol that enables users to be authenticated by collaborating websites, referred to as relying parties, through a third-party identity provider (IDP) service. This eliminates the necessity for website owners to develop their login systems while enabling users to access multiple independent websites without managing separate identities and passwords. Users establish accounts by choosing an OpenID identity provider, which they subsequently utilize to log in to any website that supports OpenID authentication.

• Kerberos: Kerberos is a third-party network authentication technology that uses shared secret keys to authenticate a user securely in an unprotected network. It was designed primarily for a client-server model, and it supports mutual authentication, which means that both the user and the server can verify each other’s identities. Kerberos protocol messages are secure from eavesdropping and replay attacks.

Workflow of Single Sign-on

An identity provider (IDP) creates an authentication server that verifies user identity and provides an encrypted access token to confirm their identity. Users are redirected to the IDP when they first try to gain access to an app or website.

For example, a company chooses Slack for team collaboration and Okta for identity management. Users must go through Okta’s authentication process when they want to access Slack. They may enter their corporate credentials or use a multifactor authentication method supported by Okta. Okta verifies the user’s credentials against the user store and makes an authentication decision by starting an SSO session if they are valid. Along with this decision, Okta may provide Slack with additional user attributes such as username, email address, etc. These attributes help Slack personalize the user’s experience and enforce any access control policies the organization sets.

While Slack relies on Okta for authentication and user attributes, it may still maintain a local account for the user. This local account contains user-specific data within the Slack platform, such as chat history. Slack workshop’s workspace

This is a free account. Click on upgrade for SAML authentication. To follow up the rest of the authentication process, check Okta/Slack authentication process.

The system authenticates the user’s session and logs them into their Slack account. Image source: Helpjuice

Here is a simple breakdown of an SSO workflow:

1. The user requests access from a website or application.
2. The application or website redirects the user to the identity provider’s login page.
3. The user enters their login credentials.
4. If the credentials are valid, the identity provider verifies the user and passes an authentication token to the SSO server.
5. The SSO server returns the authentication token to the application or website.
6. The application permits access to the user and stores the session for future use.

Prerequisites for Implementing Single Sign-on

To set up an SSO profile, you must gather some basic configuration from your IDP’s support team or documentation. Consider the following prerequisites if all your users will sign in through one IDP using SAML:

• Sign-in page URL: This is a critical component known as the SSO URL or SAML 2.0 Endpoint (HTTP). It’s the gateway where users sign in to your IDP.
• Sign-out page URL: This is where the user lands after exiting the Google app or service.
• Certificate: The X.509 PEM certificate from your IDP is critical to the setup process.
• Change password URL: This is the page where users will change their passwords instead of changing them with IDP.

Implementing Single Sign-on in Your Organization

You can set up SSO for your organization using Google as a service provider. To configure a profile for your users through one IDP using SAML protocol, do this:

1. Create an administrator account with Google and sign in to the Google Admin console.
2. Go to Menu>Security>Authentication>SSO with third-party IDP in the Admin console.
3. In the Third-party SSO profile for your organization, click Add SSO profile.
4. Check the Setup SSO with the third-party identity provider box.

Using the information in the prerequisites box, fill in the following for your identity provider:

• Enter the URLs for your IDP’s sign-in and sign-out pages. Note: Use HTTPS to enter all URLs, such as https://sso.example.com.
• After selecting Upload certificate, find and upload the X.509 certificate your IDP sent you.
• Choose whether to include a domain-specific issuer in the Google SAML request.
• If you have many domains using SSO with your IDP, use a domain-specific issuer to determine which domain is making the SAML request.
• If checked, Google sends an issuer-specific one to your domain. For instance, if example.com is your principal Google Workspace domain name, you can use google.com/a/example.com.
• If unchecked, Google sends the standard issuer in the SAML request (Google.com).
• Enter your IDP’s change password URL here. Visitors will visit this URL (instead of the Google Change password page)

To learn more, check https://support.google.com/a/answer/12032922?hl=en.

Understanding Single Sign-on Protocols

Some SSO protocols and their pathway include:

SAML

SAML is a standardized option for implementing SSO. This protocol uses XML files to exchange data about the user, the IDP, and the service provider. SAML’s key components are assertion, identity provider, and the service provider.

SAML Pathway: In an application employing single sign-on, when a user asks for a request to a resource, the application, acting as the service provider, verifies the user’s authorization by consulting the identity provider. The IDP, in turn, authenticates the user’s identity and issues an assertion confirming the user’s access privileges for the requested resource.

SAML Use Cases: SAML can enable SSO transactions. In an enterprise login SSO, users can employ SAML to access multiple applications without requiring a separate login. Additionally, in a federated SSO environment, users from one organization can utilize their credentials to access the resources another organization provides using SAML.

SAML can also enforce access control lists (ACL) and facilitate ACL transactions. In this scenario, a user seeks access to a secure resource, and the SAML service renders an authorization verdict. Authentication is typically separate from this particular use case.

OpenID Connect

OIDC is an authentication protocol that extends the OAuth 2.0 framework to provide a secure and dependable way to authenticate users across multiple apps. OIDC uses a JSON web token (JWT) to exchange information between identity and service providers. JWTs are encrypted, digitally signed tokens that contain assertions about the user’s identity.

OIDC Pathway: When a user requests access to a program, the application directs the request to the IDP for authentication. Once the authentication is complete, the IDP will prompt the user to grant access to the specified application. The IDP then generates an ID token containing identification information that the application can readily use. Subsequently, the IDP redirects the user to the program, allowing them to access it without the need to enter their credentials again.

OpenID Connect Use Cases: OIDC enables secure authentication, authorization, and API access. Some of the OpenID use cases include:

• Implicit flow is typically employed for single-page applications, where tokens are directly provided to the application via a redirect.
• Authorization Code flow is most commonly used in native, single-page, and mobile web apps. It’s designed for applications that are not reliable for storing sensitive data. This flow utilizes cryptographically signed JWT tokens, and user data remains undisclosed to the application.
• The hybrid approach merges the flows mentioned above. Initially, it issues an ID token to the application via a redirect URL. Subsequently, the application exchanges the ID Token for a temporary access token.

LDAP/AD

The LDAP allows users to access a credentials directory. Communication takes place via the LDAP Data Interchange Format (LDIF). An LDAP directory can be shared across several applications. Integrating LDAP with Active Directory (AD) enables the central AD server to store user identities. Subsequently, applications can direct authentication requests to the LDAP/AD server.

LDAP Pathway: An application sends a request to access data stored in an LDAP database. The application provides the LDAP server user credentials, username, and password. Subsequently, the LDAP server compares the user identity information stored in the AD or LDAP database with the credentials provided by the user. This user identity information, including phone numbers, addresses, or group participation, serves as a unique identifier. If the credentials provided match the stored user ID, LDAP grants access to the requested data. However, incorrect credentials will deny access to LDAP, ensuring access control measures are upheld.

LDAP/AD Use Cases: Because of its open and cross-platform nature, LDAP is applicable across many directory service providers and applications. LDAP is typically a centralized repository for credentials like usernames and passwords.

LDAP authentication is compatible with various widely used applications, including OpenVPN, Docker, Jenkins, and Kubernetes. System administrators leverage LDAP’s SSO functionality to efficiently oversee LDAP database access across multiple applications.

Selecting the Appropriate SSO Protocol

The choice of authentication protocol plays an important role when distinguishing between enterprise and consumer apps. Enterprise applications frequently use SAML because of its comprehensive support and integration capabilities with enterprise identity providers and its ability to handle intricate authentication circumstances. In contrast, OAuth 2.0 and OIDC are more suited for consumer-facing apps, as they are adaptable and compatible with mobile and online applications.

The specific authentication and authorization requirements are the foundational bedrock for SAML, OIDC, and OAuth2.0. If the primary need is authentication, which involves verifying user identification, SAML or OIDC are typically the preferred options. OIDC, built on top of OAuth 2.0, provides an additional identity layer to OAuth’s authorization capabilities. Programs use OAuth 2.0 to access user resources while keeping user passwords uncompromised.

Regarding application and platform compatibility, ensuring that the SSO protocols align with your current infrastructure and the applications you plan to integrate is crucial. While SAML may be broadly supported by some legacy or enterprise systems, modern applications often favor OAuth 2.0 and OIDC due to their API-friendly nature and ability to enhance user experience, especially in web and mobile environments.

Additionally, you should future-proof your application ecosystem. Are you migrating to cloud-based services, APIs, and mobile apps? In cloud and mobile applications, OAuth 2.0 and OIDC may provide greater flexibility and are generally considered more forward-looking.

Final Thoughts

Single sign-on is an authentication protocol that enables users to log in to websites or applications without re-entering their passwords. SAML, OIDC, and OAuth are some of the different authentication mechanisms that offer approaches to this process. This article has discussed how to implement SSO in your organization and the factors to consider when choosing the appropriate SSO protocol.

Secure Your Front-End: Detect, Fix, and Fortify

Spot abnormal user behaviors and iron out the bugs early with OpenReplay. Dive into session replays and reinforce your front-end against vulnerabilities that hackers search for.