What is Single Sign On?

What is Single Sign-On?

Now that we are versed with the ways digital identity works and its applications on the Web, we can move on to certain concepts which make it easier to use the online identity. Recollect that there is no universal identity provider on the internet which means a typical person would hold multiple digital identities in a lifetime. But that’s not the ideal situation. Ideally, one would want just one online identity acceptable throughout the Web. Sadly, that is unlikely anytime soon due to the fair absence of an authority on the Web which can issue universal online identities, which means we have to make do with smaller amends.

Two of them are the the ideas of Federation and Single Sign-On which is essentially usage of a single digital identity across multiple domains. We will only look into Single Sign-On, or SSO, in this post. As said, every domain on the Web is empowered to issue online identities but if a business owns multiple domains or applications, it doesn’t make technological or business sense for each of those multiple domains to separately issue identities to customers registering there. Technologically, this means setting up individual identity management protocols for each domain which can turn out to be redundant, as you will see. On the business side, it means asking customers to register and login multiple times seriously denting the user experience. But with SSO Login, users can be allowed to sign into multiple connected domains or applications with just one set of 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 signin for mainframe, Java or terminal based applications. Some instances also involve installation of a 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.

And then there are password synchronization solutions which are also 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?

This is a question businesses often ponder about though it has been long that Single Sign-On solutions have been in existence now. Another question a few businesses come up with is if they actually need to implement Web Single Sign-On for their domain. The answer to the second one is quite simple. Any business which has more than one website or application and allows customers to login to their networks through the websites or applications can deploy Single Sign-On for their benefit of their customers.

As far the first question is concerned, there multiple ways businesses benefit from deployment of Web Single Sign-On. Of course the benefits vary slightly depending on the SSO authentication method used. But broadly, with a Single Sign-On implementation, businesses can give their customers a vastly improved user experience. For starters, it 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. And then, businesses can use Single Sign-On as a centralization mechanism to store their customer credentials and activity information in a single location thereby avoiding multiple storage instances of the same and separate information. With this, businesses get a hawk’s eye view of each customer across all properties.

At the same time, cloud services are picking up steam which means SSO is turning into a need from a want. Most major consumer focussed automation softwares are run from cloud today which again means there is an account and login for each one of them. Cloud Single Sign-On solutions can be really handful in the cloud scenario. Technically, they are quite similar to the way a Web Single Sign-On solution would be implemented.

Which is the best mode of SSO implementation?

Well, this is like asking which is the best Harley Davidson motorcycle. There is no answer. You just have to pick and choose. SAML based SSO authentication is the most widely accepted method though several SSO solutions also use Multipass and JSON Web Token based implementation mechanisms. SAML is a slightly older method that is based on XML (which is losing out in favour of JSON in web programming). SAML is also very widely used in WS Federation, another shared authentication protocol. Integration SAML Single Sign-On on Active Directory Lightweight Directory Access Protocols (LDAP) like Active Directory also helps in better implementation. Active Directory and SAML based SSO solutions help consolidate information about an organization or a domain customers into one single repository without having to access multiple databases. However, JSON Web Tokens are more compact than SAML for SSO authentication and implementation - since they are based on the lightweight JSON - and are faster and better in a HTTP or light web application environment. In the end, it just depends on the environment and the primary users of the Single Sign-On solution.