Background:
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!
Introduction:
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?).
Lastly, user management is related to the administration (creation, deletion, and update) of user accounts. A federated identity system usually provides the means for administrators (or users) to handle accounts across domains or subsystems.
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 their 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.
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 getgo.
