What is Single Sign On (SSO) and How It Works?

Today almost all popular sites provide options to sign up with Google, Facebook, Twitter, Github or similar known and trusted services. Whenever you click the button saying ‘Sign Up with Google’ it opens a window saying ‘You are allowing the site to access your google profile’ and when you click the allow button you get logged in to the site. Very simple right! By just clicking one button you can login to the site without entering username and password. This mechanism is called Single Sign On or SSO in the short term. Have you ever wondered how this SSO thing works?

Let’s start defining Single Sign On in technical terms and understand how it works in real life under the hood without us knowing about it.

What is Single Sign On?

SSO (Single Sign On) is an authentication mechanism allowing third party trusted sites to authenticate users of your site on behalf of you. This offloads developers of implementing authentication mechanisms and not worrying about security risk of leaking username and passwords from your site.

Now as we have defined the term Single Sign On, let’s start understanding how it really works under the hood.

How Single Sign On works?

Before going into more technical details let me describe steps being performed by Single Sign On system in plain English:

• User clicks on Sign In with Google
• Site opens Google’s account login page
• If user is already logged in then it gives your site data of the logged in user
• Otherwise user logs in into the google account and google notifies the site with details of logged in user
• The site verifies that user is authorized to access the site
• If user is authorized then your site creates a session for the user and logs in the user
• When the session of the user expires, the site again performs the step mentioned above to authenticate the user.

As we have some context on how SSO works lets try to understand its working from a technical point of view. Here are the technical steps which will be performed to login you to the site:

• User opens your site website.com. Session details stored in either local storage of your browser or cookies will be sent along for authentication. Website.com will check if there is any session active for given cookies/session details. If the session is active then the user will be logged in to the site.
• If there is no session active for the user then website.com will contact the SSO system provider to generate a secret for the user.
• SSO system provider validates the site that it is allowed to use SSO authentication system. Once validated it generates a secret and provides it to the consumer (website.com).
• Website.com then redirects the user to the SSO system provider’s login page with the secret it obtained from the SSO system provider.
• Now the SSO system validates the secret and the site(website.com) that redirected the user to its login page. Once validated it checks if the user is already logged in to the SSO account. If the user is already authenticated then it shows a consent page to confirm that the user wants to authorize website.com to access the user’s SSO account profile. Otherwise it will show a login page to the user and the user will login to the SSO account by providing username and password.
• Once authenticated, SSO system will generate an access token against the user profile and the secret it has provided to the consumer(website.com) and redirects the user to the URL provided by the consumer (website.com).
• Again consumer (website.com) validates the access token and secret with the SSO systems and once verified it creates a session for the user and logs in the user to the site by setting cookie in user’s browser or sending tokens to the user and storing it in browser’s local storage.

This flow is similar to the now popular OAuth 2.0 mechanism. But there are many other protocols available in the market to implement the Single Sign On. They have introduced some variations in these steps but generating a token, authenticating users with the third party trusted service and redirecting back users with authentication details is the core part of implementing SSO. Below I am presenting the graphical view of above steps to help you understand it better:

Now lets understand why you should use SSO instead of implementing your own authentication mechanism and what are the pros and cons of using it.

Advantages of using SSO:

• Developers don’t have to implement their own authentication mechanism and by using SSO you are decreasing the complexity of your site. It is well known that complexity ~ number of bugs.
• By using SSO developers are avoiding storing users’ credentials in their database which in effect reduces the risk of being hacked and leaking users’ credentials.
• Users don’t have to go through the lengthy sign up and verification processes as the user has already completed the sign up and verification process with the SSO system provider.
• Users need to remember only one set of the password for a single sign on system. They can login to all systems which are connected to that SSO system by just logging in to the SSO system.
• By using SSO systems like Google and Facebook, users have peace of mind that their credentials are not being stored in plain text in an individual site’s database.

Cons of using SSO:

• Using SSO becomes a single point of failure for your site. If the SSO system goes down then no one using SSO to login to your site will be able to authenticate themselves.
• If any hacker is able to breach the SSO authentication system then all your systems connected to it will be open to the attack.
• Sometimes SSO can take longer than expected to set up. Each system has its unique access flow and integrating a generic SSO system into your setup can introduce unique challenges for developers.
• Some SSO linked sites may sell their users data to the third party services.