Blog

So an SSO system lets a user login to more than one website at a time using an id shared across the various systems. If you have logged in to a website using your Facebook account, then you have used an SSO system.

SSO systems are painful because there are many many things that can go wrong as you build them before they work correctly. Their very job is security and convenience. These two things are at war with one another on the Internet. With SSO there is usually one main system or service that is the owner of the user account. This system is checked or queried by the other systems to ask if the user logging in is valid and real. For these systems to be secure, most organizations impose many layers of security. There will be ip address white listing, encryption, secure tokens, password retrieval, federation, firewalls, and a slew of other details that will get in the way of you and your code letting some poor human log in to a system.

Because of the complexity, I have found, as with a lot of API work I do, the final successful result is so much more rewarding. Lately I have found that the level of complexity of these systems, at least the level exposed to me and my code, has decreased a bit. An SSO integration I recently did with ExpressionEngine and a client's internal systems was made so much easier because there was a PHP library readily available. One system I worked on used OAuth 2 which meant I could use this great library. These libs did not exist a few years ago when I first started with SSO work. They make things so much easier.

Here's how these systems usually work. (This is the OAuth version.) Pretend like you are a website and pretend like someone wants to login to you. Let's say the someone is Fiona. So Fiona clicks your login link. You bounce her to a web page owned by the web service or web site that owns your user account. Let's call it the Mothership. So Fiona is over trying to put in her username and password on the Mothership website. She eventually gets through. The Mothership bounces her back to you. (You had told the Mothership in advance where it could send people who logged in.) You had done this in advance because you had been registered with the Mothership in advance as a valid SSO partner. So Fiona is back. The Mothership sent her. This time she has a code, though. It's in the url that the Mothership used. You grab this code and you make a secure super secret squirrel call behind the scenes to the Mothership again. You say to the Mothership, "Hey, some turkey is coming to me saying she's logged in and wants to access some stuff. She gave me this little code. Do you recognize this? Is it one of yours?" The Mothership says, "Yep, that's a code I recognize. I just created it for Fiona. Here's Fiona's user information. It's encrypted and stored inside this funky looking access token. As long as you can decipher it using the key we shared when you registered, you can let Fiona do the stuff she needs to do on you." So you decrypt the access token, get Fiona's name and info along with a unique id that you pray never changes. You log Fiona into your own personal systems. Fiona has a good time and the Mothership knows very little about the party.

Sounds fun right? It is, in a not fun way. This method, though pretty solid once the kinks are worked out, can break in so many different ways. Mainly the problems are with human error. There are so many different types of handshakes and so many ways that two humans can miscommunicate about the details. But once those details are sorted, assuming the players are playing nice, you have a nice little SSO rig where people can conveniently login to multiple systems with the same id.

We build these systems as well as other API integrations pretty frequently. They're really fun and quite useful. The SSO systems are my personal favorite, mainly because all the other integrations that you might build rely on and hang off of the one SSO integration. This puts the pressure on, but that can also be fun.