Single Sign-On: What Are We Actually Looking For?

I used to work at a university. There were systems I had to log into. A bunch. On any given day I’d hop into the HR portal and log some hours or flag some time off, I’d jump on the IT portal and enter a support request, I’d log into the calendar system and rsvp to the employee free pizza night.

Each time, I’d land on that drab little login page with the university logo, and I’d jam in my Active Directory credentials. It was annoying having to log in each time but, hey, at least I only used one set of credentials, right? That's the single sign-on I was promised, right?

Wikipedia doesn’t seem to think so:

“Single sign-on (SSO) is a property of access control of multiple related, but independent software systems ... For clarity it is best to refer to systems requiring authentication for each application but using the same credentials from a directory server as Directory Server Authentication and systems where a single authentication provides access to multiple applications by passing the authentication token seamlessly to configured applications as SSO.”

Dang. Looks like I had "Directory Server Authentication" and not SSO.

Why are we doing this again?

Like most things, when someone throws out the term SSO, they’re usually referring to only a component of a much larger concept. It’s a buzzword now, single sign-on, and when we say that, we’re thinking about what it feels like as a user. But let's take a step back for a moment and consider what we’re really after – Identity Management.

Who are all these people?

Think back to my university example. I’m logging in with the same set of credentials, but each system I interact with is completely separate. The calendar system has no idea that I’m logged into the HR system. More importantly the two systems don’t share information about me as a user. It’s a step forward from having me remember a different set of credentials for each system, but we can do better. We want our systems to cooperate as a single user ecosystem. When I log into the HR system, the calendar system should already know that I’m logged in and who I am. Single sign-on is a sexy user experience feature, but more than just reducing login friction, we want to cohesively manage our user identities across all of our properties.

There are, of course, boatloads of ways to accomplish this, technically, but I’m going to speak in the abstract. Lets talk about what’s going on conceptually.

The session way.

In my example, each system has a user log in against a central directory (something like Active Directory). We call that directory an Identity Provider.

The Identity Provider validates my credentials and tells whatever system, or Service Provider, I’m trying to get into (let’s say the HR system) that I am indeed Ryan. Great! The Service Provider now sets up a session on the server and I’m up and running. This server is now responsible for storing state, that is to say the current status of me as a user logged in.

When I head over to the next Service Provider (say, the calendar) we go through the whole process again. Since my session is stored only within that first Service Provider, the HR system, the new one, the calendar, knows nothing about it.

In order to fix this we’d need to get those two Service Providers to share their sessions. Sort of possible, but difficult and messy. Especially once you start adding more and more systems to interact with.

So we have two problems with this session-based approach:

1. Sessions are not easily shared between applications.
2. Storing sessions in the application means that server has to track and manage state.

So what else can we do?

Lets get away from storing user sessions in our applications. An alternative is to use a token-based authentication strategy. I think this is probably best explained through example.

So I’m back at the HR app again. I get presented with the login screen and I give it my credentials. This time, instead of our Identity Provider telling the application that I’m legitimate, and having that Service Provider start a session, the Identity Provider gives me a token (in technical terms it’s probably giving me a JSON Web Token, or JWT). This token is signed and encrypted. It has a time to live (meaning that it will expire after a set period of time). It contains basic information about me as a user (we call these "Claims"), like my username, first name, last name, job title and permissions.

These Claims can be anything we decide to set. If our applications all need to know birthdate, fine, put it in the Claims. If we need to know my height, stick it in the Claims.

This token is stored in my browser. My browser passes it to the HR app I’m trying to get into. The HR app (the Service Provider) has the keys to decrypt my token. It does so, reads that it was signed by the Identity Provider, reads through the claims and knows the basic information about me, and I’m off and running.

That might not sound too different from the previous example, but the big difference comes when I head to another system.

I navigate over to the calendar system. My browser sends my token on over. This system has the keys to decrypt it. It does so, reads the Claims, and I’m in there.

I did not have to enter my credentials again. We did not have to route through the Identity Provider again.

We’ve made a number of improvements:

1. My logged in state is stored in my token, and thus easily shared between all the applications in our ecosystem.
2. Applications no longer need to store my user state, because that lives in the token. Our back-end applications can become stateless.
3. We actually fit into the definition of single sign-on.

There are also some ancillary benefits that might not be immediately obvious:

1. Developing new applications is much easier, because they do not have to worry much about Identity Management. They can implement the exact same login structure, and same token decryption keys. We’ve effectively standardized how our applications interface with authentication.
2. It becomes much easier to share data about users between systems.
3. Securing the tokens is actually fairly easy, by storing them in http cookies, which are inaccessible by JavaScript, and thus safe from XSS attacks.

Great. Now what?

Of course this isn’t everything we need to stand up our super cool and advanced Identity Management system, but it’s good background to get our thoughts rolling. We still need to decide on a specific technical implementation, on the architecture of our users and more.

The important thing is to take a step back and consider how your SSO implementation impacts your larger Identity Management strategy. Think of SSO as a single component of your larger Identity Management system. Understand conceptually what your goals are and how this authentication process impacts them.

Need help making sense of your organization's complex systems and how you can improve their users' experience? Contact us today.