Single-Sign On (SSO) describes an identity solution that allows multiple applications to use the same authentication session, so avoiding repetitive credential entry. SSO implementations are often adopted by companies in the enterprise world as part of their strategy to secure access to important resources. With the advent of cloud computing and the boom of Software as a Service (SaaS), companies all around the world are increasing their focus on access management strategies that can enhance both security and the user experience; implementing SSO can deliver on both aspects. From the security perspective, one benefit introduced by Single-Sign On is that, because it reduces the number of credentials required to sign into multiple services to a single credential, there are fewer credentials to be lost or stolen. In addition, multi-factor authentication (MFA), or two-factor authentication (2fA) is more likely to be enforced to protect that single, powerful, credential. From the end-user perspective, leveraging an Identity Provider (IdP) system capable of supporting SSO enhances the user experience because it drastically lowers credential entry fatigue. Additionally, using SSO means that the burden of remembering credentials for, potentially, dozens of accounts is removed. A beneficial side-effect of adopting SSO solutions is that the number of help desk calls related to password reset activities also decreases.
How does Single-Sign On Work?
Implementing Single-Sign On usually consists of defining a central service that applications rely on when a user logs in. In this approach, if an unauthenticated user requests an application that requires identity information, the app in question redirects the user to the central service. On this server, the user then authenticates and gets redirected back to the original application with identity information. There, they can move on and achieve the initial goals they had when the authentication request was triggered. After a while, if that same user moves onto another application that also requires identity information and that relies on the same central service to perform user authentication, the second application can leverage the session that the user initiated while signing in to the first application. A good example that can help illustrate how SSO works is Google and its different services. For example, when you try to access Gmail without being authenticated, Google redirects you to a central service that is hosted at accounts.google.com. There, you will see a sign-in form where you will have to input your user credentials. If the authentication process is successful, then Google redirects you to Gmail, where you gain access to your email account. Then, after authenticating through this central service, if you head to another service (like Youtube, for example), you will see that you are automatically signed in. The following diagram gives more details on how a SSO authentication process works. Assuming the user wants to access domain1.com, upon browsing to this domain they are redirected to the authentication server, domain3.com, where they authenticate. Upon successful authentication, domain3 stores a session cookie which is used for the SSO record. It then redirects the browser back to domain1 with an artifact that domain1.com can exchange for a token that may be used to prove the user’s identity for subsequent access to domain1’s services. When the user (in the same session) accesses domain2.com, domain2 redirects to domain3 for authentication. However, because domain3 has a record that the user has a login session (via the cookie) it doesn’t require the user to login interactively, and instead redirects the browser back to domain2.com with an appropriate authentication artifact, as before. Note that the SSO session valid period is determined by the authentication server (domain3) and may exist simply as long as the browser session, or for a specific period, from hours to weeks, depending on the security policy and user experience requirements. This is the essence of SSO, as with Google and others. The protocol between the authentication server and the client applications will, typically, be SAML 2.0, OpenID Connect, Kerberos or other authentication protocol that supports SSO.
How to Implement Single-Sign On with Auth0
Just like with many other authentication and authorization features, using Auth0 to implement Single-Sign On is extremely easy. If you are already using Auth0 to secure your applications, SSO is already available for you automatically. For instance, if you have two or more applications using the same Auth0 account, you will notice that users that sign in to one, they will be transparently signed into the other. You don't have to do anything special on these applications to take advantage of the SSO session. Another useful aspect of using Auth0 to enable Single-Sign On in your applications is in having a single point of control over access to resources, reducing IT resource demands. If you want to learn more about Auth0, how it helps you implement Single-Sign On, and how to secure your apps with it, you can refer to the docs.
Want to learn more?
Keep reading at our Intro to IAM page to explore more topics around Identity and Access Management.
