To hackers, the most valuable part of your website or web application isn’t necessarily just your content. What hackers are after is personal data – your users’ names/emails/passwords and any personal data that might be stored in your databases. What if you could have a centralized place, perhaps a secure, trusted third party, to manage all of your users’ logins and sessions? What if you could improve your users’ experience and reduce your IT department’s workload at the same time? You can – with SSO! 

What is SSO? 

SSO stands for Single Sign-On. It is a service that allows session and user authentication for multiple web applications or websites using only one set of login credentials. It makes for fewer headaches for both end users and administrators. The IT department no longer has to constantly reset many passwords, and users don’t have to remember so many passwords (or write them down on sticky notes all over the office, which is such a “no, no!”). 

Why and When do People use SSO?

SSO can provide many benefits for users, administrators, and organizations as a whole. It allows websites and web apps to use a trusted third party to verify user’s identities rather than just a simple single factor authentication (like a username and password combo) for each separate site or application. SSO lets organizations to be free from storing passwords locally in their own databases, which leaves them much more vulnerable to serious data breaches. It also makes troubleshooting login issues much easier. Once you are setup with a third party that provides SSO (often an identity provider or service like Active Directory, ADFS, Ping Identity, etc.), your site or application will be much more secure, streamlined, and less complicated for both you and your users.  

How does it work?

First, your user will authenticate with the identity provider on a simple login page, where they will provide a username and passwords, and perhaps a second factor for authentication like a text message or email verification. Once logged in, the identity provider verifies the user’s credentials, and their machine is issued a token, usually deposited into a session cookie in the user’s browser. Now, when the user moves around the site and between different web applications (service providers), their token is verified with the identity provider and they can access the different apps directly. 

For example, you login to your google account once and now can access google apps like Gmail, YouTube, and Drive, without having to login to each of them individually. The protocol by which the service provider and identity provider communicate to authenticate and authorize data between parties is called SAML (Security Assertion Markup Language). It’s based on XML and is basically what is going on under the hood in the SSO process.