Single Sign-On (SSO) authentication is now required more than ever. Nowadays, almost every website requires some form of authentication to access its features and content. With the number of websites and services rising, a centralized login system has become a necessity. In this post, we will study how SSO authentication is implemented for the web. Read on!
Federated Identity Glossary
The concept of a centralized or linked electronic identity is known as federated identity. Federated identity systems handle several concerns:
- Authentication
- Authorization
- User attributes exchange
- User management
The authentication aspect deals with validating user credentials and establishing the identity of the user.
Authorization is related to access restrictions (e.g., is the user allowed to access X resource?).
The attributes exchange aspect deals with data sharing across different user management systems. For instance, fields such as "real name" may be present in multiple systems. A federated identity system prevents data duplication by linking the related attributes.
Lastly, user management is related to the administration (creation, deletion, update) of user accounts. A federated identity system usually provides the means for administrators (or users) to handle accounts across domains or subsystems.
SSO is strictly related to the authentication part of a federated identity system. Its only concern is establishing the identity of the user and then sharing that information with each subsystem that requires the data. Below, we focus on this crucial aspect of a federated identity system.
Single Sign-On (SSO) Authentication
Sooner or later web development teams face one problem: you have developed an application at domain X and now you want your new deployment at domain Y to use the same login information as the other domain. In fact, you want more: you want users who are already logged-in at domain X to be already logged-in at domain Y. This is what SSO is all about.
The obvious solution to this problem is to share session information across different domains. However, for security reasons, browsers enforce a policy known as the same origin policy. This policy dictates that cookies (and other locally stored data) can only be accessed by its creator (i.e. the domain that originally requested the data to be stored). In other words, domain X cannot access cookies from domain Y or vice versa. This is what SSO solutions solve in one way or the other: sharing session information across different domains.
Different SSO protocols share session information in different ways, but the essential concept is the same: there is a central domain, through which authentication is performed, and then the session is shared with other domains in some way.
For instance, the central domain may generate a signed JSON Web Token (JWT), which may be encrypted using JSON Web Encryption (JWE). This token may then be passed to the client and used by the authentication domain as well as any other domains. The token can be passed to the original domain by a redirect and it contains all the information needed to identify the user for the domain requiring authentication. As the token is signed, it cannot be modified in any way by the client.
Whenever users go to a domain that requires authentication, they are redirected to the authentication domain. As users are already logged-in at that domain, they can be immediately redirected to the original domain with the necessary authentication token.
SSO Authentication with Auth0
If you have been reading about SSO online, you have probably found that there are many different implementations: OpenID Connect, Facebook Connect, SAML, Microsoft Account (formerly known as Passport), etc. Our advice is to choose whatever is simplest for your development efforts. For instance, SAML is deeply entrenched in enterprise developments, so in some cases, it will make sense to pick that. If you think you will need to integrate your development with more than one alternative, don't despair: there are frameworks that allow interoperability between different SSO solutions. In fact, that's one of the things we do at Auth0.
You can go and check our docs on Single Sign-On and the Auth0 SSO samples.
If you remember the Typical SSO Scenario diagram we saw earlier, you can see how Auth0 comes to play in the next diagram:
In this case, Auth0 is the Authentication Server and it works as a bridge between different SSO frameworks.
For further information, we invite you to learn more about SSO with our free whitepaper.
Download the Whitepaper
Conclusion
Single Sign-On authentication is here to stay. Decentralized systems are becoming more and more common and authentication is an essential aspect of all of them. SSO solves a big problem: how to manage the increasing number of users across a whole ecosystem of applications and services. Frameworks such as OpenID Connect and services such as the one we provide at Auth0 make integrating Single Sign-On into your new or existing applications much easier. If you are implementing authentication for a new application or service, consider integrating SSO from the get-go.
