Single Sign On (SSO) and Your Web Site: Benefits and Risks

Written by Ann Grosso ArnoldDecember 1, 2010

Have you ever wondered if Single Sign On (SSO) is right for your website? Can it be adapted for your specific needs? Will it increase user-friendliness without compromising privacy and security? Let’s see if we can sort it all out together.

First off, what is SSO? SSO is a property that allows access to multiple, related, but independent software systems. With this property, you only log in once and gain access to all systems to which you are authorized, without being prompted to log in again at each of them. (Single sign-off is the reverse property where a single sign out terminates access to multiple software systems, but that’s a subject for another day.)

That all sounds great, but it presents a certain set of challenges. Primary concerns include properly authenticating each user and, of course, maintaining privacy. You need to establish a single network identity (sometimes called a federated identity) for each user that is recognized throughout your enterprise and allows access to the specific set of applications and information authorized for that identity. 

Because a single password is used in an SSO environment, you need to be sure that a strong authentication protocol is in place. The single password becomes a source of great convenience and ease for the user, but one of risk for you and your systems. Most SSO solutions available today provide authorization as well as authentication. Once the user is authenticated using the password, authorization can be granted or restricted to permit or limit access to individual applications or information. Early SSO systems utilized a token method of authentication: a single encrypted token is issued to the user after successful authentication and then passed to all back-end systems. The majority of web-based SSO solutions however, use authentication proxies. The web-based SSO allows users to log in by way of a web page and then brokers the authentication request by presenting passwords, certificates, tokens, or similar credentials to the native application, server, or operating system.  

You need to ask yourself if there is a real business purpose for allowing a user to have complete access to your system. If the answer is yes, you need to perform two thorough risk evaluations: one on your systems that will be accessed, and one on the outside party who will have SSO access to your system. If the risk analysis determines that the systems being accessed are low risk, meaning they do not have sensitive customer data or are not used for financial transactions, then it might be worthwhile. For example, your company might be partnering with a marketing concern that uses demographic data from your sales for market research. Such data usually cannot be traced back to individual customers where it could be used for draining accounts or stealing identities, resulting in a relatively low risk.

What other benefits should you consider? Among other potential benefits, there can be a very real cost savings involved with minimizing passwords. It has been estimated that 40-50% of all help desk calls are for password resets. The more passwords a user must remember – the more likely they are to lose or forget them. The load on your in-house help desk or the number of calls to an outside help concern can be greatly reduced by using SSO.

Now let’s take a look at an example of an existing SSO that you can begin using almost immediately – Facebook! In our current climate of social networking, it is not surprising that you can take advantage of Facebook to remove the registration process for your site by enabling users to log in to your site with their Facebook account. Once a user logs in to your site with his or her Facebook account, you can access the user’s account information from Facebook, and the user remains logged in to your site as long as he or she is logged in to Facebook.

The Facebook Platform uses the OAuth 2.0 protocol for authorization. During the authentication process, the user is presented with a UI in which he or she can authorize your application to access that specific part of his or her profile. Although you can implement a complete login and signup system using OAuth 2.0 directly, the open source JavaScript SDK is a simple way to implement login and signup without worrying about the details of the protocol. It is as easy and streamlined for you to implement as any SDK from any other partner or concern that you have worked with before.

When a user logs into your site through Facebook, the SDK saves the credentials for the active Facebook user in a cookie on your site’s domain so that you can use the user’s identity easily in both your server-side and JavaScript code. It provides a single, simple callback so your application can automatically handle the complex set of authentication states that exist in a single-sign on system.

For example, if a user has previously logged into your website, but does not have a cookie for your site in the current browser, the SDK will automatically detect that condition and log the user in to your site without requiring the user to click a Facebook login button again.

The JavaScript SDK does require that you register your application with Facebook to get an Application ID for your site. In general, you should use only one App ID for your base domain; a single App ID allows you to create a full-featured application. With the API initialized, you can pop up a Facebook authorization dialog box by calling the FB login JavaScript method, or you can include the standard Facebook login button: 

By using Facebook instead of a web form, you can access all the basic account registration data you would typically request in a sign-up form for your site, including user name, email address, profile picture, and birthday. A new user can provide all of the information required for site registration with a single dialog box (no typing required!). Likewise, the information is more reliable than the information you would get in a web form. For example, Facebook has already verified the email address provided to them, so you do not need to re-verify it. Some of the basic account registration data you might need in your registration process is private, so you will need to request extended permissions from the user in the login process. For example, to request the user’s email address and birthday in the login process use the perms argument to request the required permissions. Once the user authorizes your site, you can fetch those fields from the user’s profile. In this way, if a user changes his or her profile picture for example, because each Facebook user’s profile picture can always be accessed at the same URL, you will be sure to fetch the most current picture for use on your site.

Once your app is up and running, you can get detailed analytics about the demographics of your users and how users are sharing from your application using Insights, which supports analytics broken down by application and by domain. Insights include rich data about users sharing content from your site within Facebook, no matter where those shares originated. For example, if a user puts a URL from your site into a Facebook status message, that data is included in the analytics for your domain so you can integrate the Facebook analytics data with your own, in-house analytics systems.

So, at the risk of repeating myself, is Single Sign On right for your website? It’s not a black and white answer, but I hope we’ve given you some of the risks and benefits to take into account as you consider SSO for your website as well as some of the protocols you can use to implement it. 

Social login powered by Gigya