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 two-piece post we will study how SSO authentication is implemented for the web and provide a working example using OpenID Connect (in part 2). 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.

Non Single Sign On Scenario

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.

No cookie sharing

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 (which may be encrypted using 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 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.

SSO - Central authentication domain

Whenever the user goes to a domain that requires authentication, he or she is redirected to the authentication domain. As the user is already logged-in at that domain, he or she can be immeditely redirected to the original domain with the necessary authentication token.

Single Sign On Authentication

Different protocols

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.

Aside: SSO Authentication with Auth0

If you are already using Auth0 in your developments, you know how easy it is to do SSO. If not, please see the docs on single sign on and check out the examples. Our SSO solution works as a bridge between different SSO frameworks. So whatever your existing apps are using, it has never been easier to integrate SSO into them. We do the hard work for you.

"Our SSO solution works as a bridge between different SSO frameworks."

SSO with Auth0


SSO 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.