Single Sign-On (SSO) has become an over-loaded term for many developers. It’s used, sometimes inaccurately, to refer to any tool that simplifies login for the end-user. But SSO has a very specific technical definition, and the confusion increasingly makes it difficult for developers to find the right tool for the job.

In most cases, what a developer is really looking for is one (or a combination) of three different tools: Centralized Authentication, Social Login (i.e. Facebook Login), or actual Single Sign-on.

Social Login is pretty well defined at this point, and most developers know what it is— the user logs into your application by clicking a facebook button and using their Facebook credentials (usually through a custom Facebook OAuth flow). You can learn all about it in our Facebook Login Guide.

Less clear and often more misunderstood is the difference between Single Sign-On and Centralized Authentication. At Stormpath we see this confusion often and wrote this article to help developers find the right solution for their application.

Single Sign-On

With single sign-on (SSO), users are authenticated only once, regardless of how many other applications they attempt to access after the initial login. In general, this is achieved when the SSO Identity Provider (IDP) sends the target applications an assertion that the user has been authenticated and should be trusted by that application.

For example, say a user logs on to Application 1, then decides to access Application 2. Typically, Application 2 would require another username and password for authentication. But in an SSO environment, Application 2 simply determines whether it can authenticate the user based on information the SSO IDP provides. The assertions are typically based on a common protocol like SAML, OpenID Connect, or JWT.

SSO solves two major problems for users:

  1. They don’t need to enter authentication information multiple times
  2. …or remember multiple sets of login credentials

It also requires a user repository in order to authenticate a user for the first time. Typical user repositories include Active Directory, LDAP, a custom database, or Stormpath. In turn, these same repositories are often centralized authentication and user management systems.

On its own, SSO is a poor solution for sharing user data across applications, as SSO generally expects the application (or “Service Provider” in SSO speak) to maintain its own user management system. More specifically, when an SSO provider sends an authentication assertion to an application, it still needs to create or look up the user in the app’s own local repository. Even though the application can trust that the user is authenticated.

Centralized Authentication

With centralized authentication, the authentication process is different. Once a user has logged into Application 1, logging into App 2 doesn’t feel automatic. Even though the required credentials are identical, the user would still need to enter her authentication information again.

Like SSO, Centralized authentication solves two problems, but the problems are different:

  1. Users don’t need to remember multiple sets of authentication credentials
  2. The applications they are logging into can share user data.

Typically, centralized authentication solutions completely offload user management from an application. They provide powerful APIs or query languages to connect the user system to one or many applications. Moreover, centralized authentication is often the first step toward a true SSO environment.

SSO vs Centralized Authentication? Why not both?!

So, should you use SSO or Centralized Authentication in your application? Of course the answer is: it depends.

  • If you’re trying to create a single user repository that all your applications can share, you will want a centralized authentication and user management system.

  • If, on the other hand, you have a variety of applications with their own built-in user data and management, but you want to create a seamless user experience, you’ll be best served by SSO (if those apps support it).

However, SSO and Centralized Authentication are not direct competitors. In fact, many developers implement both to give customers a seamless user experience across applications or web properties. At the same time, an SSO/Centralized Authentication combo allows development teams to share user infrastructure across applications, so they aren’t reinventing the identity system with each new application.

Stormpath combines both SSO and Centralized Authentication in one clean and elegant user management system. With an elegant API, powerful SDKs, and easy to use framework integrations, your applications have full access to user and group data .

In addition, we now offer SSO across your custom applications with little to no coding on your end through our new ID Site feature, so you can offer customers a seamless user experience.