When people ask me, “what is Single Sign-On”? I ask them to imagine going to the mall, and at each store you must register with the store for your first purchase. Then, every time after that, you have to prove who you are to buy something.

But that’s what happens when you shop for goods and services online. Each website makes you create a new and unique identity specific to that website. On top of that, you have to login and authenticate each time.

Why can’t it be like the offline world?

I can go wherever I want and just show my one universal identity (Birth Certificate, Passport, Drivers License, etc…).

While some web properties offer the option to sign in using social identity, for the most part you still have to register/login with each web property. This often happens even when the websites are operated by the same parent organization.

There are solutions out there that would make this situation a thing of the past. One of them is the idea of Single Sign-On; which is essentially using a single digital identity across multiple domains. With SSO Login, users can be allowed to sign into multiple connected domains or applications with just one username and password. In a nutshell, SSO allows for creation of online identities that are universal in a group of domains or applications.

Is Single Sign-On just Single Sign-On?

Not exactly. Single Sign-On implementation varies by environment. Primarily, there are two types of Single Sign-On solutions: Enterprise Single Sign-On and Web Single Sign-On. The concept of seamless access is common to both these sets of implementation but differ in their architecture and methods.

Enterprise Single Sign-On solutions simply manage passwords and provide one-click seamless access to applications for subsequent logins after the first sign in for mainframe, Java or terminal based applications. Some instances also involve installation of an SSO client on each enterprise terminal which helps obtain access without entering the username and password multiple times. However, all applications can be considered to be enterprise applications for internal users.

Web Single Sign-On implementations are completely different in the sense that users requesting access to domains and applications are distributed and interact exclusively with websites or mobile apps.

There are also password synchronization solutions which are often grouped as Single Sign-On solutions but aren’t the kind of SSO implementations businesses or enterprises are looking for in today’s age.

How does Web Single Sign-On work?

As explained earlier, the concept of Single Sign-On is to ensure that customers are able to login to multiple related websites or applications with just one online identity. This can be done by centralizing the process of identity provision and authentication.

So, typically, if a business owns three websites, a customer should be able to login to one of them using his or her online identity. But when the customer requests access to one or both of the other websites, he or she should be automatically signed in. In simple terms, this can be done by creating a session for the customer on first signin, which is then shared by the other domains to directly grant access to the customer without asking for credentials again.

This is the fundamental idea of Single Sign-On but while concept remains the same, its implementation varies due to multiple constraints. One is that session information of different domains or applications are not allowed to be shared by modern browsers owing to the same origin policy or sometimes cookies are just not stored by browsers.

Web Single Sign-On solutions implementations most commonly use three standards: SAML, JSON Web Token or Multipass. Irrespective of the standard in use, Single Sign-On solutions fundamentally just share session information to check if a user has already logged into a related site or not.

How does Web Single Sign-On help a business?

Any business that has more than one website or application and allows customers to login to their networks through the websites or applications should deploy Single Sign-On. Why?

Improved User experience: Single Sign-On eliminates the appearance of login pages for each site or application and users don’t have to login for each separate access in a single session. That itself is a huge boost. Centralized User Profiles: Single Sign-On can be used as a centralization mechanism to store customer credentials and activity information in a single location thereby avoiding multiple storage instances of the same and separate information. With this, businesses get an overview of each customer across all properties. Centralized Reporting and Analysis: SSO not only enables unified profiles of your customers but also centralized reporting and analysis across all digital properties. This is built-in feature with LoginRadius and can also be integrated with other analytics tools such as Google Analytics, Adobe Analytics, etc.

Which is the best mode of SSO implementation?

This really depends on your individual situation, technical architecture and business needs. I could go on here with an in-depth technical discussion on the advantages of each option but it would really make for very dry reading and make this an even longer blog post.