What is single sign-on?
Single sign-on (SSO) is a property of identity and access management (IAM) that enables users to securely authenticate with multiple applications and websites by logging in only once—with just one set of credentials (username and password). With SSO, the application or website that the user is trying to access relies on a trusted third party to verify that users are who they say they are.
How does authentication work without SSO?
Without single sign-on, each website maintains its own database of users and their credentials. This is what happens when you try to log in to an app or website:
- The website first checks to see whether you’ve already been authenticated. If you have, it gives you access to the site.
- If you haven’t, it asks you to log in and it checks your username and password against the information in its user database.
- After login, the site passes authentication verification data as you move through the site to verify that you are authenticated each time you go to a new page.
The authentication verification data is usually passed as either cookies with session data or as tokens, which don’t track the session and are faster to process.
User requests access
User is granted access
and then requests access to a new site
How does SSO work?
Authentication with SSO relies on a trust relationship between domains (websites). With single sign-on, this is what happens when you try to log in to an app or website:
- The website first checks to see whether you’ve already been authenticated by the SSO solution, in which case it gives you access to the site.
- If you haven’t, it sends you to the SSO solution to log in.
- You enter the single username/password that you use for corporate access.
- The SSO solution requests authentication from the identity provider or authentication system that your company uses. It verifies your identity and notifies the SSO solution.
- The SSO solution passes authentication data to the website and returns you to that site.
- After login, the site passes authentication verification data with you as you move through the site to verify that you are authenticated each time you go to a new page.
In SSO, authentication verification data takes the form of tokens.
User requests access
The website redirects the user to the SSO website to log in. The user logs in with a single username and password.
The SSO website verifies the user’s identity with an identity provider, such as Active Directory.
User is granted access
and then requests access to a new site
When the user tries to access a different website, the new website checks with the SSO solution. Since the user has been authenticated, it verifies the user’s identity to the new website without requiring an additional login.
What makes a true SSO system?
It’s important to understand the difference between single sign-on and password vaulting, which is sometimes referred to as SSO. With password vaulting, you may have the same username and password, but you have to enter it each time you move to a different application or website.
With SSO, after you’re logged in via the SSO solution, you can access all company-approved applications and websites without having to log in again. That includes cloud applications as well as on-prem applications, often available through an SSO portal (also called a login portal). SSO uses a concept called federation to provide federated SSO.
What is federated SSO?
SSO solutions that use federation enable true single sign-on by taking advantage of the organization’s identity provider (IP), such as Microsoft Active Directory (AD) or Azure Active Directory (Azure AD). The identity provider usually acts as the authentication server and stores the user’s identity and information, such as the username, password, domains the user has access to, and even which activities the user is allowed to do on each site or within each app. (Verifying the activities that the user is allowed to do is called authorization. For example, a user may have access to Salesforce reports but may not be permitted to edit customer records.)
For true SSO, either the SSO solution is built into the identity provider or the SSO solution uses one or more identity providers to authenticate the user.
Authentication requests and information are passed using standard, secure protocols, such as SAML or OAuth. The websites requesting authentication have a trust relationship with the SSO solution, and trust relationships exist between the SSO solution and the identity providers. A trust relationship means that one domain trusts another’s information about user identities, devices, and access privileges.
