Authentication is something that virtually every developer these days has dealt with at least once - and sometimes has purposely avoided increasing that particular counter. Security in general is hard to get right, and authentication is, arguably, at its heart. There is precious little out there today that has no need of authentication, so one would think that (1) by now there would be excellent, vetted, and widely-used authentication systems that can be plugged in to any app, and that (2) everyone uses such systems. Unfortunately, neither of those is actually true. While single sign-on (SSO) systems do exist, they are hardly universal or ubiquitous. There are the big OAuth providers like Twitter and Facebook, whose authorization services are often used by social startups for the purpose of authentication. There is the ability to use a Google account (and countless other OpenID endpoints) strictly for authentication purposes. And, of course, there's Microsoft's Passport, er, Live ID, er, Microsoft account.

There are two big issues with these systems. The first one is trust, and it is a multifaceted issue. Do your users trust the system you've chosen? Do you trust that system itself to be secure and keep your users' authentication information confidential? Do you trust your users to utilize that system in a secure manner? These are all important questions that must be answered "yes" in order to even begin considering SSO. The first trust question tends to be the simplest. Unless a significant number of your users is computer-savvy, user trust can be considered implicit. Only if there exists a very widely publicized reason not to trust a system would there be resistance from "typical" people. The second trust question is a bit tougher and requires some research into the chosen system. Twitter appears to be taking reasonably good care of their users' account security, and the same can be said of Google. However, if you choose to implement OpenID, then there are absolutely no guarantees as to how secure any of the other endpoints out there may be. And if a user's account is compromised on your website/app because their OpenID endpoint was compromised, chances are the user will still blame you. Finally, the third trust question is more open-ended and may not have a clear answer. If the system you chose potentially allows users to create three-letter passwords, for example, then maybe you wouldn't trust your users to utilize that system appropriately. Again, all of these questions must be carefully considered when determining whether to use a single sign-on system.

The second big issue with SSO is that users must already have accounts with the SSO provider. This is generally a good thing for internal corporate applications and a bad thing everywhere else. Unless your website or app's primary purpose revolves around a system that can be used as an SSO provider (e.g., a Twitter client), then you have no reason to require that a user sign up for some unrelated service. That extra signup step becomes annoying and unnecessary, and users will not respond positively to it.

Of course, there are other potential reasons not to go with SSO. Sometimes custom authentication is required for extra-paranoid security. Sometimes there are exotic requirements, such as cached offline login, that generally cannot be met by SSO systems. But if your website or app has no such issues, and if trust is not a problem and an existing user account is virtually guaranteed, then by all means go with an SSO system. It's much easier to focus on your product's core functionality when you don't have to worry about authentication. (Okay, you still have to worry about it, but only to the extent of implementing the chosen SSO system's protocol correctly.)

The next post will tackle issues of handling authentication yourself without SSO.