What is single sign-on (SSO)?
Single sign-on (SSO) is a session and user authentication service that lets users access multiple applications or systems with a single set of login credentials. By eliminating the need to remember and manage separate usernames and passwords for each service, SSO improves user convenience, reduces password fatigue and enhances security through centralized identity management.
How does single sign-on work?
Single sign-on is a federated identity management arrangement that operates through a centralized authentication system, known as an identity provider (IdP). The use of such a system is sometimes called identity federation.
When a user attempts to access an application, also known as the service provider (SP), it redirects them to the IdP for authentication. Upon successful login, the identity provider issues an authentication token, granting the user access to the application without needing to log in again.
In a basic web SSO service, an agent module on the application server retrieves the specific authentication credentials for an individual user from a dedicated SSO policy server, while authenticating the user against a user repository, such as a Lightweight Directory Access Protocol (LDAP) directory.
The service authenticates the end user for all the applications the user has been given rights to and eliminates future password prompts for individual applications during the same session.
The following is a step-by-step description of how SSO works:
Access request.
The user attempts to access a protected application or a website. The application or the SP checks if the user is already authenticated with the ldP.
Redirect to IdP. If the SP detects the user isn’t authenticated, it redirects the browser to the IdP for authentication.
User authentication.
The IdP prompts the user to enter credentials, such as their username and password for authentication.
Token generation. If the credentials are valid, the IdP authenticates the user and generates a security token.
This token is typically stored in the user’s browser session, often as a secure cookie. Redirection back to the SP. The IdP redirects the user back to the original SP or the app, passing the authentication token along.
Token validation.
The SP verifies the token’s authenticity and integrity, ensuring it was issued by a trusted IdP.
Access granted. If the token is valid, the SP grants the user access to the requested application and the user remains authenticated across all connected applications during the session, reducing the need for multiple logins.
Seamless access to other applications.
For any subsequent applications within the same SSO ecosystem, access is streamlined. When a user attempts to access a new application, the service provider checks with the IdP, detects a valid authentication token and grants access immediately.
Common SSO protocols
The SSO systems’ efficiency and security are built upon different protocols that govern how identity information is exchanged. The most commonly used SSO protocols and frameworks include the following:
Kerberos.
This is a network authentication protocol designed to provide authentication for client-server applications using secret-key cryptography. In a Kerberos-based setup, once user credentials are provided, a ticket-granting ticket is issued. The TGT fetches service tickets for other applications the user wants to access, without asking the user to reenter credentials.
Security Assertion Markup Language.
SAML is an Extensible Markup Language standard that facilitates the exchange of user authentication and authorization data across secure domains. SAML-based SSO services involve communications among the user, an identity provider that maintains a user directory and a service provider.
Open Authorization.
OAuth is a framework that enables third-party services, such as Facebook, to use end user’s account information without exposing the user’s password. It acts as an intermediary on behalf of the end user by providing the service with an access token that authorizes specific account information to be shared. When a user attempts to access an application from the SP, the SP sends a request to the identity provider for authentication. The SP then verifies the authentication and logs the user in.
OpenID Connect.
OIDC is an identity layer built on top of OAuth 2.0, which is a more comprehensive and flexible successor to OAuth 1.0. It provides a standardized method for verifying the identity of end users and obtaining basic profile information through an authorization server.
After a user authenticates with an OIDC-compliant IdP, which also functions as an OAuth 2.0 authorization server, the IdP issues an ID token, such as a JSON Web Token, in addition to an OAuth 2.0 access token. The ID Token contains verifiable information about the user’s identity, letting the client application confirm who the user is.
Types of SSO configurations
SSO can be configured in various ways depending on the authentication method and system requirements.
The main types of SSO configurations include the following:
Social SSO
This is a type of SSO that enables users to access a third-party website or application using their existing credentials from a major social media or consumer account, such as Google, Facebook, Apple, LinkedIn or X.
Many security professionals recommend end users refrain from using social SSO services because, once attackers gain control of a user’s SSO credentials, they can access all other applications that use the same credentials.
Enterprise SSO
Enterprise single sign-on (eSSO) software and services are password managers with client and server components that log a user on to target applications by replaying user credentials. These credentials are almost always a username and a password.
Target applications don’t need to be modified to work with the eSSO system.
Web-based or federated SSO
Web-based SSO uses identity federation protocols, such as SAML, OAuth and OIDC, to authenticate users across multiple websites and applications. This approach is commonly used in enterprise environments where employees need seamless access to various cloud services.
Cloud-based SSO
Cloud-based SSO lets users authenticate across cloud applications using providers, such as Microsoft Azure AD, Okta and Google Workspace. This SSO type is common in businesses adopting software-as-a-service applications that require streamlined access management.
Mobile SSO
This SSO type uses mobile authentication mechanisms, such as biometrics and device-based authentication, to grant access to multiple applications. Mobile SSO is often integrated with mobile identity providers, such as Apple ID or Google Sign-In.
Smart card-based SSO
Smart card-based SSO integrates physical smart cards with digital systems to enhance authentication security. It asks an end user to use a card holding the sign-in credentials for the first login. Once the card is used, the user doesn’t need to reenter usernames or passwords. SSO smart cards store either certificates or passwords.
This method is used in high-security environments, such as government agencies and healthcare institutions.
Read More :-
 is a session and user authentication service that lets users access multiple applications with a single set of login.){kind=link}