Overview
SSO Introduction
Single Sign-On (SSO) refers to the authentication process that allows your customers to access multiple applications with a single set of login credentials and an active login session. The following are the two examples of the Single Sign-On environments:
Where Customers access multiple applications of the same provider. Customers dont 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.
Where Employees access numerous applications daily. Employees dont 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.
Note: SSO can facilitate the following for a developer:
- Users to log in across multiple applications without re-promoting them to log in
- Users to log in to all their SaaS applications by only typing the credentials once
- Aligning SaaS applications with organizational IAM policies.
With SSO implementation, the SLO (Single Logout) is also required, i.e. if a user has logged out from one application, they should be logged out from other linked applications too.
The following is a representation of the SSO scenario:
User lands on a.com to log in, and clicking the login link redirects the user to the Identity Provider page.
On the Identity Provider page, the user enters the login credentials and gets logged into the a.com application.
Later, the user lands on the b.com to log in, clicking the login link redirects the user to the Identity Provider page.
Since the user is already logged in on the Identity Profile, the user is 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 user 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 user authentication status from the Identity Provider. In the SSO ecosystem, the IDP is considered a Master.
Taking the LoginRadius Identity Platform into consideration, if you have multiple websites and want to establish SSO and SLO across them, these websites will act as Service Providers, and LoginRadius will act as Identity Provider.
The LoginRadius Identity Platform allows you to implement SSO in the following ways:
Web SSO
Web SSO is a method of browser-based session management that utilizes browser storage mechanisms like sessionStorage, localStorage, cookies to maintain the user’s session across your applications. When the Single Sign-on is required between two or more web applications and LoginRadius Identity Platform acts as an Identity Provider.
A centralized domain managed by LoginRadius IDX is utilized to perform the authentication. When requested, this centralized domain shares the session with authorized applications. For more details on Web SSO refer to our documentation here.
Mobile SSO
Mobile SSO works by storing the LoginRadius access token in a shared session, either shared preferences in Android or keychain in iOS. It allows you to identify a currently active session and access the current sessions’ user data to initialize your user account in each linked app.
When the Single Sign-on is required between two or more mobile apps and LoginRadius Identity Platform acts as an Identity Provider. For more details on Mobile SSO refer to our documentation here.
Federated SSO
When the Single Sign-on is required between two or more web applications and LoginRadius Identity Platform either acts as Identity Provider or Service Provider. This comes handy while implementing SSO with third-party applications. For interaction with third-party web applications, LoginRadius Identity Platform supports SAML, JWT, OAuth, and OpenID SSO protocols.
Accept tokens and identities issued by niche identity providers of your choice and allow your customers to authenticate on your website for seamless transactions. Identity providers can be your organizational partners who already issue and hold digital identities/tokens/tickets. With LoginRadius Federated SSO, your business can leverage that identity and make authentication seamless for your customers.
 Domo |
 Ms SharePoint |
 Atlassian Jira |
 Salesforce |
 OAuth2 |
 JWT |
 OIDC |
 SAML |
Custom IDPs
This can be understood as Social Login. You can use it to configure a designed Social Login provider for your web application(s), which is not available in the default social login providers list by the LoginRadius Identity Platform.
Custom OAuth Provider is the most implemented protocol by the customers to set up a custom Identity Provider. LoginRadius provides a wide range of social providers for social login. Custom Identity providers are used, where customers requirement is not getting fulfilled by the provided range of social providers in LoginRadius
 Doximity |
 Alipay |
 |
OAuth2 |
JWT |
SAML |
SSO Connectors
There are some third-party applications that do not support industry-standard federated SSO methods like SAML, Oauth/OIDC, JWT, etc. and provide their own mechanism to create a Single Sign-On workflow for identity provider applications.
LoginRadius provides out of the box SSO Connector solutions to create a Single Sign-on user experience between LoginRadius and these applications by leveraging these mechanisms. For more details on Password Delegation refer to our documentation here.
 Shopify |
 Big Commerce |
 Perfect Mind |