How to identify a client in several websites. Single Sign On, What is it, and what is it for?
One of the most common demands in any internet business is to be able to identify our visitors by their names and surnames. Knowledge is power. This would allow us to engage mechanisms to increase conversion by offering related products based on previous searches, purchases, wish lists, preferences, etc. Internet…
One of the most common demands in any internet business is to be able to identify our visitors by their names and surnames. Knowledge is power. This would allow us to engage mechanisms to increase conversion by offering related products based on previous searches, purchases, wish lists, preferences, etc.
Internet is based on a stateless protocol. To be specific, we refer to HTTP (Hypertext Transfer Protocol), where by definition, each of the requests our pages receive is anonymous and independent. This situation has been circumvented over time by adding registration forms and logins that, together with cookies, enable us to identify users to our websites. So far, so good. What happens, however, when there are several websites that use our strategy for capturing online data?
Most websites prefer to use separate registration systems. In other words, users must register for each web separately, leading to understandable frustration at having to enter personal data over and over again.
Faced with this problem, the technical solution was to add a “centralised login database” or SSO (Single Sign On) in technical terminology.
This means that a user can log into multiple sites, but the credentials are shared by the different websites. As always, it is more straightforward in theory than in practice, and a number of solutions have been presented in recent years with varying degrees of success. Here are just a few of them:
Implementation of SSO in a server:
In the golden years of the early 2000s, companies wanted to introduce customised SSO systems. On a personal note, it was one of the first jobs I was given straight after university. The idea was to implement JOSSO (implementation of SSO in Java) for an e-learning platform that consisted of different modules. Although it did work in the end, it was a demanding job requiring several weeks of work from 2 full-time engineers.
There is an example of its use in the following diagram:
– It is a working centralised identification system
– It is difficult to implement
– It calls for additional system infrastructure
This is a standard that was initially developed in 2005 for the OpenID Foundation (non-profit organization). It is the closest thing to an attempted internet DNI. The benefits are basically the same as for an SSO, namely that a user with credentials can be identified across different sites. The main difference lies in how it works, as each user possesses a unique url for identification with OpenID suppliers, which are external webs that manage user credentials and information.
In other words, when you create an OpenID account, you must choose an identity supplier to create your account. Some of the OpenID suppliers are:
Below is a simplified diagram showing how it works:
– It is much easier to implement, because there are plugins for the main platforms: WordPress, Prestashop, Magento, etc.
– It is an advanced identification system which is too technical for basic users, which means it has a limited number of users.
– It has been criticized for delegating data storage and the details of user’s sites to a third party.
You can find more information at http://openidexplained.com/
Facebook Connect has made centralized login systems popular. Over 1400 million accounts have been created in Facebook.
It was a good idea, using a system everyone knows to identify yourself across the internet.
– Very easy to implement on websites
– Enables access to additional information from the user’s profile
– People are unsure about how Facebook will manage their privacy. Will content be published on my wall when I am identified?
– The Facebook button, which at first meant “Share” or “Like” is still confusing for less advanced users.
Implementation of SSO as SaaS (Software as a Service):
The aim here is to return to a centralized login system, where the user does not need to do anything specific (install OpenID or have a Facebook account), but which is still easier to implement in websites. Services such as Gigya have appeared, which offer a decentralized login system for different domains and sub-domains.
In the next article I will explain our experience of installing Gigya in a digital communication service, what the process involved, the technical choices for integration, pros and contras, etc. I hope you find it interesting.