How Single Sign On Works – Explained

In this post, our authentication expert will share his experience with user authentication. We’re sure you will recognize yourself at times, and will realize some issues with the password handling approaches you take. We will end up explaining very technical aspects of Single Sign On in pretty simple words, step by step.

A Long Path to SSO

Security while working with data is an undoubtedly important thing. You understand that you need to secure your bank account or mail box and you never have a thought that this part of the online life can be omitted. However, my personal experience is telling me that too much security can have the opposite effect as it conflicts with other important things like ease of use and comfort of working with online services.

Passwords

My first online security item was a dialup connection password given by my ISP in the nineties and I still remember this set of letters and digits. It was so unusual comparing to cool passwords used in movies like ‘GOD’, ‘SEX’ or ‘123456’, though I am still using the last one sometimes, and it was a pretty easy task to remember this very first password. However, soon I had to create a mailbox account that also required a password, and then the second mailbox, a college web site account, active directory account and now there were already five passwords to remember!

Ok, I can do five, but then Facebook, Twitter, Google, MSDN, StackOverflow, IMDB, the best-of-all recipes site and more and more. And you know the most terrifying fact? Some of them require CHANGING the password from time to time! Well, since I can remember five passwords, I started to use them with all sites that required an account. This made things much easier: when trying to logon, just try the first password and if it does not work, use the next one and so on. Easy and secure!

But what the heck? How did it occur that my 68 level Orc has been stolen?! Ah, the best-of-all recipes site database has been revealed by a 14-years hacker and it happened that I used the same email/password for my WoW account.

Secure Password Storage

Ok, I’ve got it: using the same passwords for all accounts is a bad idea. But if I cannot remember all the passwords I need, I can just write them down! And to avoid spending a half of life searching for a notebook or whatever, let’s use a genius invention, one of the most life-changing breakthroughs of the XX century – sticky notes!

I was sure that this is a great idea until my IT guy gave me a good lesson and changed all the passwords sticked to my display. Ha-ha, very funny 🙁

Ok, I’ve got it: I need to password protect my passwords! So, I put them to an Excel file and saved it to my flash drive. I must say this was quite inconvenient. Now, when I needed to recollect a password, I had to get my flash drive, attach it to my PC, open the file by typing another password (I had to remember this one – e.g. Justin!Bieber!Sucks) and then find the needed service on the list that had grown up to 119 records by the time! However, the advantage of this approach is obvious: I do not have to remember every password. If I need to logon to the Game of Thrones fan site, I just need to get my flash drive from this pocket… or this one… Hmm, where is it? Maybe in the car? Oh God – it seems I forgot the drive at home!

The Ideal Solution

OK, I’ve got it. I need to find a solution which satisfies some conditions. I should be able to:

1. Have accounts on a hundred of websites.
2. Log in to these sites without a necessity to look into a notepad or file to recollect a password.
3. Ensure that unreliable websites will not lose my email and password that are used on some other websites.
4. Reduce the number of passwords to remember.

All these conditions can be met if I delegate the authentication of my person to a single secured service that is trusted by all the websites I need to work with. The idea is simple: login to this service with the only password I have in mind (e.g. WinnieThePooh#RockStar) and ask this service to confirm my personality to any other services.

And this is exactly how Single Sign On works! Congratulations – we have just re-invented this technology.

The most popular trusted service of such a kind is Google. You sign in to Google using your good and reliable password (e.g. DukeNukemMustDie100500!) and when you need to login to another service, e.g. your ClickHelp documentation portal, just click Log in with Google and… that’s it, you’re logged in! Moreover, it is even possible to do this automatically: when someone tries to access a web page (help topic, article, etc.) that requires a user to be logged in, ClickHelp and similar services just ask Google to confirm a user personality without even showing any login dialogs or warnings. You are being logged in automatically to a third-party service that does not know anything about your favorite password (e.g. MikeJaggerVsPredator) and, therefore, cannot lose it.

That is why the idea of SSO is getting more and more popular now. It resolves a bunch of problems and makes your work in the global network easier and more secure at the same time. I will tell you more about how this thing works, keep reading.

Single Sign On – The Essence

Now we know that SSO can help us be secure on the web and it frees us from remembering hundreds of logins and passwords (like Heisenberg%Freeman). Let’s talk about the general idea of this approach and try to understand how SSO works in general.

How do I Get to the Party?

We have a goal – get to a party without a personal invitation, but with a friend well known in this place that can tell the guy at the entrance that you are together. Let’s decompose this situation. We have the following acting elements:

1. You, the visitor.
   Or your user agent – a favorite browser, e.g. Lynx.
2. A nightclub.
   Or a service with something interesting. Otherwise, why would you want to get in there?
3. Your friend.
   Or a well-known, trusted service that provides the Single Sign-On option (e.g. Google).
4. The guy at the club entrance.
   Or the login page of the service with something interesting. Though login pages are often more user-friendly…

Source: Wikimedia Commons, CC BY 2.0 License

You want to get into the club and decide to go directly to the tough guy at the entrance. He starts frowning at you and asks for an invitation. Instead of taking your invitation out of your pants (I mean the back pocket of course), you tell him that you know Larry (everybody knows Larry!), and he can confirm that you are a worthy person to be allowed to get inside.

Still frowning, the guy at the entrance gets his phone and dials Larry, “Hey, Larry. What’s up bro? It’s me, the guy at the entrance. I have a dude here that claims you know him and can vouch for him. Yeah, sure.”. Then he gives you the phone and you greet Larry, “Hey! It’s me, the guy…”, and then, very quietly so no one can hear you, add, “who wears underpants with kittens riding pink elephants.”. After Larry recognizes you, the gadget is returned to the guy at the entrance. The guy listens to Larry for a while, then looks at you with a smile and lets you into the club smirking.

So, this guy at the entrance let you in even without an invitation, seeing you for the first time in his life! And this is just because both of you know Larry very well. And the most awesome part is that almost all guys at entrances of almost all nightclubs know Larry!

And now, here is the same situation with accessing a web service. You open the login page of the service you want to use. Without entering any credentials, you click the Login with Google button. The service redirects you to the Google login page so you can introduce yourself to it. You specify your login and password (e.g. Pussy$Riding@Elephant1) or just approve sending some of your identification data to the third-party service if you already logged in via Google in this browser session. Google sends a direct request to the service telling who you are. The service gets this information, and then returns to you with a new page, allowing the access.

Pretty much the same, yeah? No, still don’t see the similarities? Look at the image below then.

No Password? How Can This Be Trusted?

You may think that this scheme makes your personal data almost public and vulnerable to not very honest services. In a general case, this is not true. Only a limited portion of information about you is given by the SSO provider to a third-party service. However, there are situations when the SSO provider not only identifies you to the service, but also allows it to act on your behalf in the provider’s own services. A good example is Twitter that allows a third-party service to tweet using your name.

Anyway, any respectful SSO provider always tells you what exact amount of access is requested by a service you try to log in to. Moreover, the SSO providers are not required to respond to authentication requests of any services. They can strengthen security by being a little paranoid and selective when choosing whether this specific service can utilize the provider (this time it’s Bill, not Larry).

Flawless Security

So, we have found out that the Single Sign-On way makes authentication on multiple resources more convenient and secure. Usually, these two notions are likely to be opposed: more comfort harms security (like sex without a rubber) and vice versa (a rubber without sex). The cool thing is that using SSO makes this conflict significantly less sharp. The fact that you do not have to make up ways to remember dozens of passwords or take risks using the same password everywhere eliminates the main security flaw: the gasket between a display and a chair. A user needs to keep in mind only one password “to rule them all”, so this password can be very complex and therefore secure (e.g. M1(r0h@rd5l1pp3rs).

Source: John Klossner

The main problem is that humans will be humans and the password still can leak. In this case, a malefactor can get access to dozens of accounts owned by this specific human being. So, the SSO provider must maintain the security of its service at a very high level. The most obvious requirement is high complexity of a password: it must be at least eight characters long with both lowercase and uppercase letters, digits and symbols (forget about GOD or 12345).

Another great thing that significantly increases the security level is a multi-step authentication. Besides a password, it can include another authentication step requiring:

• a unique code sent with an SMS to the registered mobile number;
• some biometrics like using a fingerprint, retinal or foot shape scanners;
• a radio badge, a smart card, a USB key or a rare Amulet of Holy Data that cannot be sold or stolen.

Tom Cruise, Minority Report movie

Except for the risks of losing the master password, you can imagine another potential significant disadvantage of using Single Sign-On: the SSO provider downtime. If and when this happens, you cannot use any of the bound services. However, this still can be treated as a plus: stop staring into the display and go for a walk!

SSO Standards

When thinking about Single Sign-On usage for web services, it is necessary to understand that this is a relatively new functionality and standards in this area are quite new. This means that there are still a lot of different SSO implementations.

The first wide-spread standard was released in 2010, and it was OAuth. The most famous service that uses this protocol is Twitter. Two years later, the standard of the second version of this protocol has been released – OAuth2. Both versions of the protocols provide not only authentication of a specific user, but also a way to authorize a third-party service to act on behalf of the end user while working with the OAuth provider.

Although there are standards, and it may look obvious that they are a good thing to follow, some services have their own Single Sign-On API’s. This makes client developers implement special support for such API’s. The best known service of this kind is Facebook. However, I like another example: Mozilla Persona launched in 2011. Have you ever heard about it? Most probably not, because Mozilla is decommissioning this project now. And this is why you should not reinvent the wheel.

The OAuth protocols are good for allowing Instagram post your selfies to Twitter. However, if we return to our initial example with just having a possibility to log in to various services without using a password, their functionality seems to be surplus. And here the OpenID standard comes into play with its current version of OpenID Connect 1.0 published in 2014. It provides a secure way to simply authenticate a user and nothing more. The standard is supported and used by such large service providers as Google, Microsoft, IBM, Steam, Crazy Dave’s Taco (perhaps) and many others. The standard smells like something really interesting at the moment, and so we will return to sniff it better in the remaining part of the post.

The OpenID Connect Way

Starting from this point, I will be extremely serious.

What’s The Difference?

So, why is OpenID Connect the most promising SSO protocol at the moment? There are several specifics that answer this question.

• It is based on OAuth 2.0, and it does NOT use SAML. If you do not know what SAML is, don’t waste your time trying to figure out. If you know what it is, well… you don’t need this knowledge to work with OpenID Connect.
• It is based on OAuth 2.0 and can be used anywhere: in web, mobile or native applications on any platforms.
• It works with JWT (JSON Web Token) that are very easy to handle and can be very secure at the same time. We will talk about this later.
• It is rather simple so can be easily integrated with basic applications. But, at the same time, its possibilities can satisfy even enterprise systems.
• Although OpenID Connect is based on OAuth 2.0, it is isolated from the “auth” part and focus on the other “auth” part instead! (you got this pun, right?)
• Google uses it. This is the strongest argument, as you understand.

So, the question now is why can’t we just use OAuth? We can, but all we want is authentication and handling the authorization features of OAuth adds some unneeded work we do not want to do. Let’s return to the example with the nightclub. In case of OpenID Connect, Larry just tells the guy at the entrance who you are and the guy decides whether you can go inside, and what you can do there. In case of OAuth, the guy gets plain instructions from Larry that you may go inside and even get into Larry’s private room with his personal strip-dancer, but only for half an hour! After this, the guy should kick you out of the club.

The REST Request, or There And Back Again

The basic authentication flow (its web version) consists of several requests that can be described with a fancy word “REST”. And this is a really nice thing that makes OpenID Connect easy to implement and still rather secure. The picture below shows these requests, starring:

1. The End-User armed with his or her favorite web browser.
2. A Relying Party (RP).
   This is the service you want to get access to. Let’s assume that the end-user wants to log in to an online documentation authoring tool like ClickHelp. So, ClickHelp is the Relying Party in our example.
3. The OpenID Provider (OP).
   This is a service that authenticates the end-user for the RP. Let Google be the OP for this example.

So, here is a short description of these 7 wonders requests/responses:

1. Trying to open a page with the needed content. This is a usual GET request made by the favorite browser (which is Lynx, remember?).
2. A response to the first request is a redirect to the OP login page. The redirect request contains a couple of short parameters like in the example below. Line breaks in the URL below are for my convenience (well, for yours, as well).

   
   https://accounts.google.com/o/oauth2/v2/auth?
    client_id=733281388907-f5dpdjikqk4kbga464vlqes6pu9chnr7.apps.googleusercontent.com&
    response_type=code&
    scope=openid%20email&
    redirect_uri=https://doc.clickhelp.co/oauth2/&
    state=s%3D73D6697B-5CEF-470C-B2F8-D083227B2443%26return_uri%3Dhttps%3A%2F%2Fdoc.clickhelp.co%2Farticles%2F%23!clickhelp-documentation%2Fgetting-started&
    nonce=8BE4146D-E81F-4261-903A-BFEA475DA105&
    prompt=login
    
   

   The interesting parameters for now are client_id, that is the identifier of the RP (Google must know who talks to it), response_type which tells that we need to get an authorization code and scope that denotes that this is actually an OpenID Connect request. The rest of the parameters are boring security stuff.

3. This is a very simple step. The user-agent gets the URI taken at step #2 and navigates to it with a common GET request. So, the user is being blessed with the OP (read “Google”) login page.
4. And it is here where the magic begins! Once the OP gets credentials from the user personally, the gears start turning without any user actions. The OP directly connects to the RP and gives it an authentication code that identifies the level of access that can be provided to the user. It is Larry telling the bouncer that he knows this nice guy and confirms that he can be trusted. Technically, this is performed with a GET request from the OP to the RP using the endpoint registered beforehand on the OP side by the RP (so Google knows the corresponding endpoint of ClickHelp).

   
   https://doc.clickhelp.co/oauth2/?
   state=s%3D73D6697B-5CEF-470C-B2F8-D083227B2443%26return_uri%3Dhttps%3A%2F%2Fdoc.clickhelp.co%2Farticles%2F%23!clickhelp-documentation%2Fgetting-started&
    nonce=8BE4146D-E81F-4261-903A-BFEA475DA105&
    code=4/i3vSqSPJlCN6DbcG2RwzQnC7wVML52Bs8GaHya2iqbg& 
    authuser=0&
    session_state=90d3c77ffffb731046b0b4d67846550d6aff8772..8b97&
    prompt=login
   
   

   The code parameter is the authorization code that is the most important piece of data in this set of bytes. The value of the state parameter is exactly the same that was passed initially from the RP to the user agent (Lynx) with a redirect request and then passed to the OP with the browser GET request. It is like a marked bill used by the RP to be sure that the received code is genuine.

   At this point, I have to show you a photo of cute kittens to keep your interest in reading further:

   

   Are you still here? Thank you!

5. Now, the code can be used within a REST request to get an ID token from the OP.

   
   POST /oauth2/v4/token HTTP/1.1
   Host: www.googleapis.com
   Content-Type: application/x-www-form-urlencoded
   
   code=4/i3vSqSPJlCN6DbcG2RwzQnC7wVML52Bs8GaHya2iqbg&
   client_id=733281388907-f5dpdjikqk4kbga464vlqes6pu9chnr7.apps.googleusercontent.com&
   client_secret=r4nBtlFikL402U3AfqXJl-vo&
   redirect_uri=https://doc.clickhelp.co/oauth2/&
   grant_type=authorization_code
   
   

   The request is sent to the OP token endpoint. Its parameters include the code, received at the previous step, the “client id” and a new thing named “client secret”. You can treat client id as a login and client secret as a password for the RP to login to the OP. There are some other parameters, but they are boring and we do not want to talk about them now. BTW, the client_secret value in the above example is my real private secret – do not tell this to anyone, please!

6. This step is a response to the request from step 5. The response contains JSON with an authorization token like this:

   
   {
    "access_token": "ya29.CjXZAt6MIUe-rgGXQQcwGyt4Fbo31IF4B6Y_GPA2CZMhQa4tuxQqK8nFaG3yxOAHINASB2pd8g",
    "token_type": "Bearer",
    "expires_in": 3599,
    "id_token": "blah.blah.blah"
   }
   
   

   We will talk about id_token later. For now, it is enough to know that this ID token contains info about a unique identifier of a user provided by the OP and can be used by the RP to authorize the user.

   A good question is why do we need steps 5 and 6 in this scheme? Why doesn’t the OP just return this token at step 4? And the answer is client secret that is required to be sent directly from the RP to OP without ever been passed to the user agent machine.

7. Now, the RP knows everything about you (your name, height, Social Security number, etc) and can let you start using its services. So, if we return to our example, you can start creating content in ClickHelp.

The Tolkien

So, all these requests hither and thither were to get an ID token. This token is a JSON Web Token (JWT) that contains some Base64Url encoded information on an identity. Generally, a token looks like this abracadabra:


TG92ZSwgbG92ZSwgbG92ZQ0KTG92ZSwgbG92ZSwgbG92ZQ0KTG92ZSwgbG92ZSwgbG92ZQ.VGhlcmUncyBub3RoaW5nIHlvdSBjYW4gZG8gdGhhdCBjYW4ndCBiZSBkb25lDQpOb3RoaW5nIHlvdSBjYW4gc2luZyB0aGF0IGNhbid0IGJlIHN1bmcNCk5vdGhpbmcgeW91IGNhbiBzYXkgYnV0IHlvdSBjYW4gbGVhcm4gaG93IHRvIHBsYXkgdGhlIGdhbWUNCkl0J3MgZWFzeQ0KDQpOb3RoaW5nIHlvdSBjYW4gbWFrZSB0aGF0IGNhbid0IGJlIG1hZGUNCk5vIG9uZSB5b3UgY2FuIHNhdmUgdGhhdCBjYW4ndCBiZSBzYXZlZA0KTm90aGluZyB5b3UgY2FuIGRvIGJ1dCB5b3UgY2FuIGxlYXJuIGhvdyB0byBiZSB5b3UgaW4gdGltZQ0KSXQncyBlYXN5.QWxsIHlvdSBuZWVkIGlzIGxvdmUNCkFsbCB5b3UgbmVlZCBpcyBsb3ZlDQpBbGwgeW91IG5lZWQgaXMgbG92ZSwgbG92ZQ0KTG92ZSBpcyBhbGwgeW91IG5lZWQNCg0KTG92ZSwgbG92ZSwgbG92ZQ0KTG92ZSwgbG92ZSwgbG92ZQ0KTG92ZSwgbG92ZSwgbG92ZQ0KDQpBbGwgeW91IG5lZWQgaXMgbG92ZQ0KQWxsIHlvdSBuZWVkIGlzIGxvdmUNCkFsbCB5b3UgbmVlZCBpcyBsb3ZlLCBsb3ZlDQpMb3ZlIGlzIGFsbCB5b3UgbmVlZA


The string consists of three parts delimited with dots: header, payload and signature. Header and Payload are just JSON strings Base64Url encoded. I beg you – do not bother decoding it, I will do this for you (formatted the result for readability):

{
 "alg": "RS256",
 "kid": "37eb40d33a4602a91bf3f56c18cfa44019f2c3ed"
}
.
{
 "iss": "https://accounts.google.com",
 "at_hash": "biCq6lDDFHH87sMYp-Lk1g",
 "aud": "733281388907-f5dpdjikqk4kbga464vlqes6pu9chnr7.apps.googleusercontent.com",
 "sub": "105641634572887320032",
 "email_verified": true,
 "azp": "733281388907-f5dpdjikqk4kbga464vlqes6pu9chnr7.apps.googleusercontent.com",
 "email": "freddy.krueger@elmstreet.com",
 "iat": 1462476389,
 "exp": 1462479989
}

The header part of the token contains information on the hash algorithm used to sign the token. The payload contains actual data with the user identifier (sub) and, optionally, the user’s email. These two pieces of data are generally used by an Identity Provider to validate the identity of the user.

Discover The Standard Simplicity

One thing that I wanted to add is that when you work with a specific OpenID Connect Provider, you do not need to know information about all OP settings and endpoints. The OpenID Connect standard has an optional but very handy feature – the Discovery document. It is like the Discovery channel – allows you to know a lot of useful (and not very) things without going anywhere from where you are. This document must be always accessible by the same URI and contains the actual settings and endpoint URIs of the corresponding provider. For example, look into the Google Discovery document that is actually a JSON string:

https://accounts.google.com/.well-known/openid-configuration

{
 "issuer": "https://accounts.google.com",
 "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
 "token_endpoint": "https://www.googleapis.com/oauth2/v4/token",
 "userinfo_endpoint": "https://www.googleapis.com/oauth2/v3/userinfo",
… blah-blah-blah

OpenID Connect – The Summary

That’s all about general OpenID Connect workflow! As you can see, it is quite simple (comparing to a spaceship) and not so difficult to understand and use (comparing to chopsticks). OpenID Connect, as well as other Single Sign-On approaches, is not something that should scare you, it really makes the life easier!

Good Luck!
ClickHelp Team