What is SSO (Single Sign On)?
SSO (Single Sign On) means that when a user logs in to one application he will be "automatically" signed in to every other application, regardless of the platform, technology and domain.
For example, Google implements SSO for their products: Gmail, YouTube, Analytics, etc. When you turn on your computer and access Gmail, you login for the first time. Then, if you go to YouTube you won't be prompted for credentials again.
The way this works is by means of a "central service" (in the case of Google this is https://accounts.google.com). When you login for the first time a cookie gets created on this central service. Then, when you try to access the second application, you get redirected to the central service, but since you already have a cookie, you get redirected to the app directly with a token, which means you're already logged in.
Single-sign-on (SSO) is now required more than ever. In this two-piece post we will study how SSO 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)
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 (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.
Whenever the user goes to a domain that requires authentication, he or she isredirected 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.
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 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.
Conclusion
SSO 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.
Reference Link:
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.
Whenever the user goes to a domain that requires authentication, he or she isredirected 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.
No comments:
Post a Comment