Single Sign On (SSO)

In the interconnected business world, we often use multiple applications for different purposes. While these may solve the purpose, managing various logins across these applications is cumbersome. That is where Single Sign-On (SSO) comes in to make the process more seamless and secure.

In this section, we will explore SSO, its components, various flows, and enterprise requirements for SSO.

Overview

Single Sign-On (SSO) is an authentication method that allows users to access multiple applications with a single set of credentials. Users can authenticate once and gain access to various systems without logging in again or maintaining multiple credentials for each application.

Below are some benefits of Single Sign-On (SSO) specifically for B2B applications:

• Enhanced user experience: It allows users to access multiple applications using a single set of credentials, reducing the need to remember numerous passwords. It also minimizes the number of login prompts, leading to a better user experience.
• Improved security: Centralization authentication enhances security by reducing the risk of weak passwords and password reuse across applications.
• Simplified user management: SSO simplifies user management for IT admins by allowing them to manage user access and efficiently apply consistent policies across applications.

These are some of the benefits of Single Sign-On (SSO). Further, it is essential to understand how it compares with other popular authentication methods. In the table below, we compare some of the popular authentication methods, such as password-based, OAuth, and multi-factor (MFA), for different parameters. This will help you choose the right method for your applications.

Single Sign-On Components

A typical SSO implementation has the following components:

• Identity Provider (IdP): The identity provider authenticates users and issues access tokens. It also stores and manages user identities and credentials.
• Service Provider (SP): The service provider is an application the user wants to access. It relies on the IdP to validate the user’s identity.
• Authentication Token: Issued by IdPs, authentication tokens contain information about the user’s identity.‍
• Federation Protocols: These protocols facilitate the authentication and authorization data exchange between IdPs and SPs. Some standard protocols are SAML and OpenID Connect, which we will discuss later.

Single Sign-On Flow

Understanding SSO flow is crucial to understanding how SSO streamlines the authentication flow.
Below is a typical SSO flow:

• A user attempts to access an application (Service Provider)
• The Service Provider redirects the user to the Identity Provider (IdP) for authentication.
• A user attempts to A user provides their credentials to the IdP, which validates their identity.
an application (Service Provider)
• IdP issues an access token to the user.
• The user presents the access token to the service provider, who validates the token and grants access to the application.
• The user can now access other Service Providers without needing to re-authenticate.

What we saw here was a typical SSO flow with all the components. One thing to note is that, though the sequence diagram simplifies how authentication and token exchange work, different federation protocols play a crucial role in securely exchanging authorization and authentication data between service providers and identity providers. In the following section, we’ll look at SAML and OpenID Connect.

SAML-based SSO

Security Assertion Markup Language (SAML) is a widely adopted protocol that enhances the standard SSO flow by defining XML-based messages that standardize and facilitate the secure exchange of authentication and authorization data between IdPs and SPs.

SAML Components

Below are the key SAML components

SSO has a suite of benefits:

• SAML Assertions: Assertions are at the core of SAML authentication, enabling the secure transfer of user identity and attributes between IdP and SP. Based on these, the SP grants or denies access to resources. Assertions consist of:
  
  • Authentication Statements: These confirm that the user has been authenticated.
  • Attribute Statements: These provide additional information about the user, such as email, roles, etc.
  • Authorization Decision Statements: These indicate the user's access rights.
• SAML Attributes These carry additional data within the SAML assertion, enabling SPs to enforce fine-grained access control and customize user experiences. Some common attributes include:‍
  • ID: A unique identifier for the user.
  • Email: The user's email address.
  • Roles: User roles or group memberships.
• SAML Metadata: SAML Metadata contains the configuration details about the IdP and SP. The IdP metadata includes entity ID, Single Sign-On (SSO), and Single Logout (SLO) endpoints. For the SP, it contains details like the Assertion Consumer Service (ACS) endpoints, entity ID, and certificates. It facilitates interoperability by allowing entities to share and understand each other's configuration.
• SAML Bindings: These define how the SAML messages are transmitted between the SP and IdP. For example, the HTTP Redirect Binding specifies how SAML messages can be sent via HTTP Redirect requests, while the HTTP POST Binding describes how to send SAML messages in an HTTP POST request.
• SAML Profiles: These provide a blueprint for implementing SAML in different scenarios by defining how assertions, protocols, and bindings can be combined. For example, the Web Browser SSO Profile outlines how to achieve single sign-on functionality in web applications using SAML components.

Along with the standard SSO components, these provide a streamlined and secure way of dealing with authorization and authentication data.

SAML Flow

Let us understand how the SAML flow differs from the vanilla SSO flow.

• The user attempts to access an application (Service Provider)
• The Service Provider (SP) generates a SAML authentication request and redirects the user to the Identity Provider (IdP) with this request.
• The user provides their credentials to the IdP, which validates them.
• After successful authentication, the IdP generates a SAML assertion containing the user's identity and authentication information and sends it back to the user.
• The user forwards the SAML assertion to the SP, which verifies it.
• Upon successful authentication, the user is granted access to the application.

What we saw here was a typical SSO flow with all the components. One thing to note is that, though the sequence diagram simplifies how authentication and token exchange work, different federation protocols play a crucial role in securely exchanging authorization and authentication data between service providers and identity providers.

In the following section, we’ll look at SAML and OpenID Connect.

Implementing SAML SSO

With employees interacting with multiple applications, implementing SSO in your B2B applications is not just a nice-to-have feature but a mandatory requirement. From offering enhanced user experience to improved security and simplified user management, implementing SSO using SAML makes all this possible while making the entire process seamless and secure.

Let us look at the high-level steps in implementing SAML SSO in B2B applications.

• ‍Requirement Gathering: You start by identifying the applications that need SSO, the required user attributes and permissions, and the identity providers your clients use.‍
• Choosing SAML Library: The next step is choosing the appropriate SAML library for your tech stack. For instance, if you use Python, you can use the pysaml2 package. Provide code snippets or pseudo-code to illustrate how to integrate these libraries.‍
• Setting Up Service Provider: Setting up your application as a service provider requires you to generate the specific SP metadata, set up endpoints for receiving SAML assertions, and configure ways to handle SAML responses. You must also configure routes in your application to handle SAML requests and responses and create a Single Logout endpoint for handling logout requests.‍
• Integrating With Identity Providers: This step involves setting up a connection with the IdPs. Configure your app with IdP metadata that includes EntityID, SSO URL, SLO URL, and certificates, and store these securely. Further, you need to tweak your application to handle multiple IdPs.‍
• SAML Request and Response Flow: Implement the SAML request and response flow. For example, when the user attempts to access a protected resource, generate a SAML request, sign it, and then redirect the user to the IdP’s SSO URL with the SAML request. Similarly, configure the SAML response flow and set an endpoint to receive a request from the IdP, validate it, and process it.‍
• Handling User Attributes and Roles: Once the SAML response is validated, implement the logic to extract user details from SAML assertions and map them to your application’s user model.‍
• Session Management: Develop and implement session handling mechanisms to securely maintain the user’s authentication state with your application.‍
• Error Handling and Logging: Robust error handling and logging mechanisms should be implemented for troubleshooting and auditing.

This was a high-level overview of the steps involved in implementing SAML SSO in B2B applications. While the steps mentioned above will be the same, how you implement them will change depending on many factors, such as your tech stack, framework, IdP, audit requirements, etc.

Many IdP providers are out there, and choosing the right provider is critical. There are several considerations that one must keep in mind. Some of them are:

• Ease of integration: Each SSO provider has different integration steps. Hence, you should choose one that integrates easily with your application.
• Feature Compatibility: Different IdPs offer different functionalities beyond the basic SAML SSO. Thus, knowing what you need helps you choose the IdP that suits your requirements.
• Support: You want to choose a provider with a good support plan that suits your requirements.

Let us look at some of the most prominent SAML SSO providers.

• Microsoft AD
• Google
• Okta
• Auth0

To understand the complete implementation process, read our blog post on implementing SAML SSO using Okta.

SAML Security Vulnerabilities

We mentioned earlier that SAML SSO provides additional security benefits to the basic SSO flow. However, it is not immune to security vulnerabilities. As with any protocol, there are chances for exploits, and hence, understanding these vulnerabilities is crucial to ensure the integrity and safety of their SAML-based SSO implementations.

In this section, we will look at some of the common SAML security vulnerabilities.

• Man-in-the-Middle (MITM): These attacks occur when an attacker intercepts the information exchange between the service provider and identity provider and modifies the SAML message in transit.
• Forged Assertions: This vulnerability exploits weak validation mechanisms for SAML responses. It happens when an attacker creates a counterfeit SAML assertion that appears valid to the service provider.
• Cross-Site Scripting: This vulnerability involves inserting malicious code or scripts into the SAML attributes field, which the application then executes after successful validation.
• Cross-Site Request Forgery (CSRF): This vulnerability can occur when the service provider’s endpoint for SAML responses is vulnerable to cross-site requests, allowing attackers to access applications.
• Poor Session Management: Incorrect session handling after the SAML request is authenticated can lead to vulnerabilities, including session fixation or stale sessions that lead to unauthorized access.

These were some of the SAML security vulnerabilities to be wary of while implementing SAML for your applications. For more details, refer to the OWASP SAML Security cheat sheet.

SAML vs OAuth

Two of the most prominent protocols for authorization and authentication are SAML and OAuth. While both protocols aim to provide secure access to resources, they have different designs and use cases. In this section, we will examine both SAML and OAuth, highlight their USPs and differences, and eventually help you choose the right solution for your B2B application.

SAML Highlights

• Used for SSO in enterprise applications.
• XML-based protocol.
• Provides authentication and authorization.
• Used mostly in web applications.
• Support for identity federation.

OAuth Highlights

• Used majorly for authorization of API requests.
• Uses JSON web tokens (JWT) as the token format.
• It handles authorization and is often used with OpenID Connect for authentication.
• Used mostly in mobile and web applications.
• Allows fine-grained access control.

‍

The below table highlights the differences between SAML and OAuth:

When to use SAML

• For enterprise-grade SSO implementations.
• Browser-based applications in corporate environments.
• In situations where user attributes need to be exchanged.

When to use OAuth

• Authorization of API requests.
• Mobile or native applications.
• When you need fine-grained access control to resources.

While these are a few generic use cases of when to use SAML or OAuth, the answer ultimately depends on your specific use case, the systems you are integrating with, and your B2B clients.

OIDC-based SSO

OpenID Connect (OIDC) is built on top of the existing OAuth2.0 protocol and extends OAuth's authorization capabilities to provide a standardized authentication method. It has become one of the most popular authentication protocols for web and mobile applications. It combines simplicity and security, thus making it an attractive option for developers implementing SSO.

Let us look at some key features of OIDC:

• In-built support for authentication.
• Standardized claim sets for user details.
• Discovery mechanism for the provider.
• Support for both web and native mobile apps.

OIDC Components

OIDC introduces additional components and concepts for authentication while inheriting the robust security features of OAuth 2.0. Key components of OIDC include:

• OpenID Provider (OP): Similar to the Authorization Server in OAuth, it authenticates users and issues tokens.
• End-user: The user whose information is contained within the ID token.
• Relying Party (RP): Similar to a client in OAuth, it relies on the OP to authenticate and retrieve user information.
• ID Token: A JSON Web Token (JWT) issued by the OP, containing user information (claims) about the authenticated end user.
• Claim: The end user's properties, such as their name and email, help the RP identify the user.

OIDC leverages OAuth 2.0 to securely enable user authentication and identity management, simplifying the process for both users and applications and providing a consistent experience across different platforms and services.

OIDC Flow

OIDC standardizes the authentication flow and allows applications to verify user identities and obtain their profile information while providing a secure and seamless experience. Below are the steps involved in a typical OIDC flow.

• The user attempts to access a protected resource.
• RP redirects the user to OP’s authorization point.
• The user provides credentials at OP and provides consent.
• OP redirects the user back to the client with a token.
• RP verifies the token and allows access to the requested resource.

Implementing OIDC SSO

Implementing OIDC SSO in B2B applications can significantly enhance security, streamline the user's complete access flow, and facilitate access management across multiple systems.

Here is an example code snippet for configuring OIDC in a Python application:

‍

Here is a high-level overview of the implementation steps and key considerations.

• ‍Requirement gathering: Identify the requirements of your B2B application, such as supported OIDC providers, scope requirements, and user information.‍
• Choose OIDC provider: Choose an OIDC provider that meets your security requirements and integrates well with your applications.‍
• Register your application: Register your application with your OIDC provider and obtain the client credentials.‍
• Configure redirect URLs: Configure your application to handle the authorization code and tokens by configuring the redirect URLs.‍
• Implement Authorization Endpoint: Modify your application to direct the users to the OIDC provider’s authorization endpoints to initiate the authentication process.‍
• Token exchange: Implement the logic for handling tokens from the OIDC provider’s token endpoint.‍
• Retrieve user information: Use the tokens to access the protected resource and fetch user profile information from the OIDC provider’s user info endpoint.‍
• Session Management: Implement session handling mechanisms to securely maintain the user’s authentication state with your application.‍
• Error Handling and Logging: Robust error handling and logging mechanisms should be implemented for troubleshooting and auditing.

This was an overview of the steps involved in implementing OIDC SSO in B2B applications. The steps mentioned above will remain the same, but how you implement them will change depending on many factors, such as your tech stack, framework, OIDC provider, audit requirements, etc.

Many OIDC providers are out there, and choosing the right provider is critical. There are several considerations that one must keep in mind. Some of them are:

• Ease of integration: Each OIDC provider has different integration steps. Hence, you should choose one that integrates easily with your application. Further, maintain flexibility to support multiple OIDC providers if your B2B applications interact with different client environments.
• Security: Verify that your OIDC provider complies with relevant security standards and ensure it supports robust encryption methods.
• Scalability: Assess the OIDC provider's ability to handle high authentication requests and loads at peak hours.
• Support: Ensure that the OIDC provider has adequate technical support and documentation available when you need them.

Let us look at some of the most prominent OIDC providers.

• Microsoft AD
• Google
• Okta
• Amazon

Read our blog post on implementing OIDC SSO using Google to understand the complete implementation process.

SAML vs OIDC

SAML, as we know it, has become a cornerstone for authentication in enterprise applications over the years. OpenID Connect has gained significant traction in modern web and mobile applications in recent years. In this section, we will look at the features of SAML and OIDC, along with their differences, to help you choose the appropriate solution for your use case.

SAML Highlights

• Matured protocol with great enterprise adoption.
• Used for web-based SSOs.
• Rich attribute exchange capabilities.

OIDC Highlights

• Built on OAuth2.0, designed for web and mobile apps.
• Easier to implement and maintain.
• Provides both authentication and authorization.

The table below highlights the differences between SAML and OIDC:

When to use SAML

• For enterprise-grade SSO implementations.
• Browser-based applications in corporate environments.
• When detailed user attributes need to be exchanged.

When to use OIDC

• Used mainly for web and mobile applications.
• When working with RESTful APIs.
• When both authentication and authorization are required.

SAML and OIDC have their strengths and weaknesses, but the choice depends on your needs, existing infrastructure, application, and clients. Sometimes, you might want to use both these protocols to accommodate different needs.

Enterprise SSO Requirements

SSO has become a critical component of most enterprise environments, allowing seamless and secured access to applications with single credentials. It enhances the user experience by reducing the need for multiple logins for end users and introducing a centralized authentication process for administrators.

You must consider some key requirements when implementing SSO in your organization.

• Robust security: Enhance the security of your applications by implementing multiple forms of verification, such as passwords, MFAs, etc. Ensure you also use strong encryption algorithms to secure token transmission and storage.
• Scalability and performance: Design your SSO solution in a way that it can scale as required at peak demand. It should handle high volumes of authentication requests without performance degradation.
• Integration capabilities: Build your solution with flexibility in mind. Make room to support multiple authentication protocols - SAML, OIDC, OAuth, etc. to ensure compatibility with other applications and services. Provide APIs and SDKs to facilitate seamless integration with custom applications.
• User experience: Keep the user experience paramount and provide users with a smooth and intuitive experience, minimizing login disruptions and improving productivity.
• Compliance and governance: Compliance is critical for enterprise applications. Ensure that your SSO solution complies with relevant regulatory requirements. Implement comprehensive logging and monitoring to track authentication events and detect anomalies.

These are a handful of requirements that you should be aware of while implementing SSO in your organization. They will help you enhance security, improve user experience, and ensure secure and seamless integration with diverse systems and applications.

Implementing SSO in B2B Applications

As discussed earlier, SSO is not just a good feature; it is a must-have in the continuously evolving business and technology landscape. Implementing SSO in B2B applications should be a strategic move to enhance security, streamline user experience, and simplify access management across multiple systems.

In this section, we will share key considerations and best practices for implementing SSO in B2B environments. We will explore key aspects of choosing the right protocol, delivering a seamless multi-product experience, effective session management tips, and implementing Single Logout (SLO) to improve your organization's security posture.

Multi-product experience

With multiple applications being accessed and used by users, a seamless multi-product experience in SSO ensures users can navigate between these services and applications with a single set of credentials. Achieving this involves some critical considerations:

• Consistent UI/UX: Providing a consistent user experience is critical. Standardize the branding, navigation, and login/logout flows across all applications, making accessing them easier for your users.
• Centralized user directory: One of the perks of using SSO is that you can offload authentication and authorization to external providers. In addition, you can use a central IdP like LDAP, Active Directory, Okta, etc., to manage identities and automate user provisioning and de-provisioning using Standard for Cross-domain Identity Management (SCIM) standards.
• Unified auditing and monitoring: Implement a centralized auditing and monitoring solution that fetches details from across the applications, provides a comprehensive audit trail, and detects threats in real-time.

By focusing on these areas, you can create a secure, seamless, and cohesive multi-product experience that enhances user productivity and satisfaction.

Session Management

Another crucial requirement when dealing with SSO is effective session management. When your users are accessing multiple applications using multiple IdPs, it becomes critical to manage sessions correctly for security and good user experience. Some of the things that must be kept in mind while dealing with sessions are mentioned below:

• Session Handling: Implement policies for token expiration and handling. Use distributed session techniques to maintain session persistence across your application instances. Silent token renewal techniques can also be deployed to obtain new tokens without disrupting the user’s current session.
• Token management: Implementing robust mechanisms to handle tokens—access and refresh tokens securely—is critical for delivering a consistent user experience across services and applications. Also, implement re-authentication techniques to ask the user to reauthenticate periodically based on your application’s requirements.
• Logging and monitoring: Implement mechanisms to log session activities, including token issuance, refreshes, etc., and maintain an audit trail. Further, monitoring and alerting tools should be implemented to detect any unusual activity.

Focusing on these will help you implement robust, secure, and seamless session management, providing session continuity that improves the productivity of users using your B2B applications.

Single Logout

Single Logout (SLO) is a crucial feature in SSO environments, especially in B2B environments where users access multiple interconnected services. SLO ensures that once the user logs out from one application, they are automatically logged out from the other, maintaining a consistent experience. This prevents unauthorized access by ensuring all active sessions are properly terminated. 

In this section, we will look at what is necessary to implement SLO in your environment.

• Protocol Support: Ensure that your IdP and SPs support SLO. For SAML, you can verify support for HTTP or SOAP methods. For OIDC, ensure that your IdP and clients are configured to handle the end_session_endpoint for initiating logouts.
• Implement proper SLO flow: The logout process starts when the user initiates a logout from any interconnected service. Ensure that your application or the IdP sends out a logout notification to all the other services so they can invalidate the session.
• Token Handling: Implement a mechanism to invalidate tokens upon logout. Ensure that all logout requests are authenticated and authorized. Lastly, keep a log of all logout activities for auditing purposes.

Focusing on these implementation tips will help you implement SLO in your environment and provide a secure and seamless user experience.

Types of SSO Flows

SSO can be implemented differently in B2B environments depending on the requirements and the use cases. The two primary types of SSO include:

• Service Provider (SP) Initiated: User begins authentication at SP’s site.
• Identity Provider (IdP) Initiated: User begins authentication at IdP’s site.

Both these flows achieve the same functionality but in a different way. The initiation points and sequence of interactions between the user, IdP, and SP vary across the flows.

In this section, we’ll look at both SP-initiated flows and IdP-initiated flows.

Service Provider Initiated SSO

Service Provider (SP) Initiated SSO is a common authentication flow in which the user starts the login process at the service provider's site. This approach is widely used in B2B environments where users access different services from a central portal. By initiating the SSO process from the SP, users can seamlessly log in to multiple services without needing to manage separate credentials for each one.

SP Initiated Flow

A typical SP-initiated flow involves the following steps:

• The user accesses a protected resource on the Service Provider (SP).
• The SP redirects the user to the Identity Provider (IdP) with an authentication request.
• The IdP prompts the user to authenticate (e.g., enter username and password).
• Upon successful authentication, the IdP generates an authentication response and redirects the user back to the SP.
• The SP validates the authentication response from the IdP and grants access to the protected resource.

Implementing SP-Initiated Flow

Below are steps that you can follow to implement SP-initiated flow.

• ‍Configure IdP: The first step is to configure your IdP with SP’s URLs where the authentication requests will be sent. Accordingly, metadata exchange must be configured based on the protocol chosen - SAML or OIDC.‍
• Service Provider setup: Implement logic to redirect unauthenticated users to the IdP SSO endpoint with a valid authentication request, including parameters like issuer, destination, and other endpoint URLs, depending on the protocol.‍
• Response validation: Implement logic to handle authentication responses and validate them along with the ability to extract data from the request.‍
• Session management: Create a user session upon successful authentication and then have logic to manage the session to provide a seamless experience to the user.‍
• Error handling: Implement error handling mechanisms to handle cases of failed authentication, unauthorized access, expired tokens, etc.

Following the above steps, you can configure and implement SP-initiated SSO flow in your environment.

Use Cases

As discussed earlier, SP Initiated SSO is preferred when the user starts the login process directly from the service provider’s application or portal. Below are some common use cases, along with examples:

• Corporate intranet portals: Employees log in to the portal (SP) to access their HRMS. The SP redirects them to the corporate IdP for authentication.
• Collaboration & productivity tool: Employees log in to a project management tool (SP) to collaborate with their team. The SP redirects them to the corporate IdP for authentication.
• Learning management system: Students log in to the LMS portal (SP) to access their course material. The SP redirects them to the university’s IDP for authentication.

Identity Provider Initiated SSO

Identity Provider (IdP) Initiated SSO is an authentication flow in which the user logs in at the identity provider’s site. It is often used when the IdP is a central authentication hub for multiple services.

IdP Initiated SSO Flow

In IdP Initiated SSO, the authentication flow typically involves the following steps:

• The user navigates to the Identity Provider (IdP) and logs in using their credentials.
• After authentication, the user selects the desired Service Provider (SP) from a list of available applications or services.
• The IdP generates an authentication response containing the user's authentication information.
• The IdP redirects the user to the SP with the authentication response.
• The SP validates the authentication response from the IdP and grants user access after successful validation.

Implementing IdP-Initiated Flow

Below are steps that you can follow to implement IdP-initiated flow.

• ‍Configure SP: Configure your SP with URLs where the authentication requests will be sent. Accordingly, metadata exchange must be configured based on the protocol chosen - SAML or OIDC.‍
• Identity Provider setup: Implement logic to handle user logins. Provide a list of applications/services the user can access after authentication.‍
• Response validation: Implement logic to handle authentication responses and redirect them to the selected SP with the authentication response.‍
• Service Provider configuration: Configure a user session and have logic to manage it to provide a seamless user experience.‍
• Error handling: Implement error handling mechanisms to handle cases of failed authentication, unauthorized access, expired tokens, etc.

Use Cases

Identity Provider (IdP) Initiated SSO is preferred when the user logs in at the identity provider’s authentication portal, providing seamless access to various service providers (SPs). Here are some common use cases, along with examples:

• Centralized employee portal: An employee logs in to the central portal and is presented with a list of applications (HRMS, Project management, etc.) they can access without needing to log in again.
• Educational institutions: A university can provide a centralized student and staff portal. Students and staff can log in once and access applications like LMS, attendance, facility services, etc., without needing to log in again.
• SaaS platform: A user logs in to a SaaS platform, and from there, they can choose other services (calendar, email, drive, etc.) that they want to access without needing to log in again.

SP vs IdP SSO

In this section, we will compare SP-initiated and IdP-initiated SSO flows, as each has its own advantages and disadvantages. Let's look at the differences between both flows.

In this section, we understood Single Sign-On and the benefits it brings to working with multiple applications. We also looked at protocols like SAML and OIDC, which are widely used for implementing SSO workflows. We touched upon various enterprise requirements for implementing SSO and understanding Service Provider and Identity Provider-initiated SSO flows.

In the next section, we’ll look at social logins and learn how to use different social media platforms to log in securely to different applications.

‍