Single Sign-on: How it really works?

Security has always been a major concern when developing websites and applications. At this modern age, we typically utilize multiple systems, each having their own security implementation. Since the most common type of security handles the age-old username and password combination, this will, if you’re one of those people who refuse to reuse their passwords, also require you to memorize tons of ‘em. Sure, you can just use a single password across all your accounts, but that will most probably be a recipe for disaster.


Pro tip: Don't be like this kid.

To avoid such catastrophe to happen, there have been various ways to improve security for end users, and Single Sign-On is one them.

So, what is it?

Commonly referred as SSO, Single Sign-on has its widespread appeal as one of the best solutions for increasing security and making multiple application access more manageable. SSO, at high level, means that you have one set of username and password for accessing multiple applications. Imagine all your favorite (and, well, hated too) applications; Facebook, Twitter, Instagram, Google, Lazada, to name a few, having just one set of username and password. That really helps relieve some stress on our brain cells!

How is it done?

SSO can be implemented in many ways, which usually follows a standard or protocol, as well as multiple technologies that can implement the aforementioned standards/protocols. Remember the well-known applications I’ve mentioned earlier? Well, some of them are already using SSO. Both Facebook and Google are using what they called SAML. Security Markup Language, or SAML protocol (or specifically SAML 2.0) is one of the standards commonly used for implementing SSO.

Another commonly used standard is the CAS protocol, standing for Central Authentication Service. Both of these technologies were something I’ve tried working on for a project (though it is more of the latter), and I can attest to the complexity of working with it, from understanding the concepts to actually doing the steps for implementation. Though we don’t have much space to delve more into the comprehensive details, we’d be discussing, in overview, how things work, in order to provide a basic understanding, on the next sections.

How do they work?

To start off, let’s just use the two protocols mentioned before. The CAS protocol, as the name implies, will have a central application that will handle the authentication between multiple applications by simply logging in through the central application’s login page. Normally, a CAS server is setup as the central application or the middle man of the authentication process. For example, having a setup with a CAS server which has access to a database with the list of users, and two applications protected by the CAS server:

  1. A user behind a browser attempts to access the email application secured by the CAS server. 
  2. The email application asks the CAS server if the user is already logged in. The CAS server validates if the user is indeed logged in. If such is valid, the user can already access the email application without the need to login.
  3. If not, the user is presented with the CAS server login page. After entering valid credentials, the CAS server gives the email application a token that provides the information that the user has authenticated successfully.

Once the user successfully authenticates against the CAS server, the photo application is also readily accessible without the need to login again, thanks the CAS protocol.

For SAML protocol, it basically involves two kinds of entities, a Service Provider and an Identity Provider. We can refer to them as SP and IdP, respectively. These entities use metadata for establishing and determining identity itself and other entities, as well as messages meant for communicating with other entities, such as requesting and responding to authentication. Both of them are in XML language, as the name of protocol suggests. The SP handles the authentication in front of the application, and the IdP determines if the user’s access power.

To help explain things, here is a simple diagram of the most common (and honestly, the least complex) implementation of SAML:

  1. A user behind a browser attempts to access a resource secured by an SP. The SP validates the user’s identity if it is already logged in.
    If yes, the process proceeds directly to step 6.
  2. The SP generates a request and provides it to the user. The SP also redirects the browser to the IdP.
  3. The user issues the request in a form of a message to the IdP.
  4. The IdP validates the request and responds by generating a response message and hands it to the user.
  5. The user issues the response to the SP.
  6. The SP process the response and creates a security context of the user’s identity, if non already exists. The SP then redirects the user to the requested resource.
    If the user’s security context already exists, the SP responds by redirecting the user to resource.

SAML protocol is actually a primitive technology relative to the CAS protocol, and thus, it can be cumbersome. But up until now it is still one of the commonly used protocol, because, simply put, it works. Like the CAS protocol, it is possible to have multiple applications that can do SSO with a single authentication server, or in its own context, multiple SPs for a single IdP, though multiple IdPs is also possible.

In conclusion

Single Sign-On right off the bat is a great concept since it provides end users easier access to multiple applications using only one set of credentials. But more than that, SSO provides better security. Take for example, with the CAS protocol, you’ll only have to enter your username and password once but you’ll immediately gain access to the several applications protected by the CAS server, thus it minimizes the number of times exposing your credentials to other fraudulent entities.

Aside from its clear benefits, it also has some downsides. One of the most obvious will be the high level of complexity as SSO is sort of complicated. But having the right knowledge and patience plus having a clear goal (and well, it’s mostly required nowadays), SSO can be a big advantage if implemented correctly.

Primary Photo by Markus Spiske on Unsplash

Blog Posts by Jihad Talic