Guide to Digital Identity - Part 4 (Single Sign-on)

Guide to Digital Identity - Part 4 (Single Sign-on)
Photo by Proxyclick Visitor Management System / Unsplash
Follow my blog with Bloglovin

When it comes to Digital Identity concepts, Authentication is one of the most important. The previous articles of the Guide to Digital Identity series have included the knowledge bundle for it. In continuation, this article is dedicated to Single Sign-On (SSO), which is also an authentication concept.

What is Single Sign-on (SSO) and how it works

Single Sign-On (SSO) refers to the authentication process that allows consumers to access multiple applications with a single login credential and an active login session. The following are the two examples of the Single Sign-On environments:

  • Consumers access multiple applications of the same provider; they don't need to create and remember separate credentials for each application; they log in once and access various applications of that provider. Example: Google, Youtube, Gmail, etc.
  • Employees access numerous applications daily; they don't need to create and remember separate credentials for each application; they can log in once and access various applications used in the organization. Example: HR Portal, Resource Portal, Organizational Account, etc.

SSO can facilitate the following for a developer:

 

  • Allowing consumers to log in across multiple applications without re-promoting them to log in.

  • Aligning SaaS applications with organizational IAM policies.


With SSO implementation, the SLO (Single Logout) is also required, i.e., if a consumer has logged out from one application, they should be logged out from other linked applications.

The following is a representation of the SSO scenario:

  1. Consumer lands on the a.com to log in, clicking the login link redirects the consumer to the Identity Provider page.
  2. On the Identity Provider page, the consumer enters the login credentials and gets logged into the a.com application.
  3. Later, the consumer lands on the b.com to log in, clicking the login link redirects the consumer to the Identity Provider page.
  4. Since the consumer is already logged in on the Identity Profile, the consumer gets automatically logged into the b.com application.

Where a.com and b.com applications are the service providers (SP). Since we have been using the Identity Provider and Service Provider terms, let’s have a quick look at their definitions:

  • Service Provider: The consumer visits this application for service—for example, eCommerce application. In the SSO ecosystem, the SP is considered a Slave.
  • Identity Provider: The service provider receives the consumer authentication status from the Identity Provider. In the SSO ecosystem, the IDP is considered a Master.

An Identity Provider never shares the account credentials with the service providers. Thus, it protects consumer data and adds on to the security aspect.

Types of SSO

Web/Mobile SSO: The Single Sign-on capability on the browser/mobile level across applications. In this, typically, the same organization owns the Identity and Services; thus, the SSO can be established with methods like session sharing or cookies.

The diagram in the section above is an example of Web or Mobile SSO if the a.com, b.com, and Identity Provider belong to the same organization.

On-Prem SSO or Enterprise SSO (e-SSO) is also an SSO type, which is almost deprecated since Web SSO can fulfill SSO’s need for both on-premises and cloud applications.

Federated SSO: The Single Sign-on between applications, where Identity and Services do not belong to the same organization. To establish the authentication process between these applications, standard protocols like SAML, JWT, OAuth, OpenID, SCIM, etc. are required. These protocols are known as SSO Protocols.

The diagram in the section above is an example of Federated SSO if the a.com, b.com, and Identity Provider do not belong to the same organization.

There is a lot to talk about when it comes to Federated SSO and those details will be covered in the next article of Guide to Digital Identity series.

When should you use SSO for Websites/Apps

The following are a few example use cases, where SSO is extremely useful to fulfill your business requirements:

  • As an organization, you have multiple Web and Mobile applications that need to be accessed by your employees (in office and remotely). Rather than managing Identity Information for each application, you want to store and use the identity from one source for authentication and authorization.
  • As an organization, you have employees and independent contractors who need to access your application(s). However, the access rights and identity source of both the roles  are different. Employee details are stored in on-premises IAM, and contractor details are stored in a separate source. Thus, at present, your application has multiple identity sources for the authentication and authorization processes.

    Cloud-based identity and access management (CIAM) solution or Identity as a service (IDaaS) can make handling this use-case more robust for you by storing the identity details of both employees and contractors in the same source for the authentication process.  Also, the authorization i.e., access, is provided to employees and contracts based on their roles.

    You can allow the employees to access their account on the other SSO enabled application and also restrict the contractor access to only one application.
  • As an organization, you have multiple web and mobile applications that are used by your consumers. For the seamless user experience and quick authentication, you don’t want the consumers to create their accounts on all those applications. SSO turned out to be the best solution in such cases. For example - an Amazon account lets you log in to both e-commerce and media platforms of Amazon.
  • As an organization, you want to use external well-known identity providers to access your application to save a lot of your consumers’ time and provide a seamless user experience. For example - Login with Facebook, Login with Google, etc.

The identity providers do not share consumer account passwords with involved parties. Typically an authentication token is shared using the SSO protocols, does consumer data remain protected and secure.

This use case is commonly known as Social Login. Social Login is a form of Single Sign-on (SSO).

How SSO benefits your business

Reduces Password Fatigue: Remembering one password instead of many makes consumers’ lives easier. As a result, consumers tend to set up strong passwords.

Reduces IT Efforts: There are multiple scenarios related to this benefit:

  • Consumers with just one password to access all their applications won’t require assistance as often.
  • Any change in account or credentials requires modification once, and SSO enables the use of updated information across linked applications. Thus, reducing the IT efforts involved in the maintenance.
  • In the case of enterprises, when the employee leaves, revoking the access of one account revokes access from all the SSO linked applications.

Streamlines User Experience: It is one of the most valuable benefits of SSO. As repeated logins are no longer required, consumers can enjoy a modern digital experience. The benefits for enterprises include an increase in consumer loyalty and higher conversion rates.

Increases Conversion Rate: SSO makes the sign-up and login process easy and fast, which increases the application adoption chances and results in higher consumer conversion.

Improves Identity Protection: SSO combined with MFA ( multi-factor authentication) or 2FA (two-factor authentication) add ons to the security aspect of the application.

The next article will be about Federated Identity Management (Federated SSO) - describing its protocols, how it works, and when and why you should use the Federated Identity Management.