SSO: OAuth & OpenID. OMG!

Van Product Owner naar Digital Product Manager door Sander Bast

25 maart 2011

“You know what would be nice? If we could let users login into our site with just their Facebook, Twitter, Hyves or any other social media site we can think of.”….

It’s a sentence I keep hearing and seeing more and more and with good reason: it makes life easier for everybody. But there are many techniques to incorporate such as a single sign-on (SSO) system and most people will shout terminology like OpenID and OAuth. But there are many systems with each site using their own system or systems: Twitter uses OAuth to authenticate, Facebook got it’s own “Facebook Connect” and many other sites uses OpenID. So the single sign-on is not so single anymore. What could possible go wrong…

Authentication vs authorization

It’s mandatory to understand the difference between authentication and authorization when dealing with systems like SSO. Authentication tells you who you are while authorization tells what somebody is allowed to do. There is a big difference: when somebody is authenticated, it doesn’t mean he or she is authorized to do stuff. We only have established somebody’s identity. This is what a system like SSO needs.

Authorization systems are more or less “the next step” in that process. Not only will it authenticate a user on behalf of a site but it will also authorize that site to do “something” on behalf of the user.

You see the difference? Authentication just tells a site: “yup, that guy on your site really John Doe”, while authorization tells the site: “That guy there is John Doe, you can see his data or do something on behalf of him now”. A really big difference, and a very important one.

In essence, authorization requires authentication but not the other way around. So when you use a authorization protocol for authentication, you are doing too much work and gaining too much privileges. On the other site: it’s up to the user to either accept or deny the authorization. But let’s be honest: how many Twitter users actually understands what they are about accept or deny. All they want is to login into your site with their Twitter login.

OAuth vs OpenID

Now lets consider OAuth versus OpenID: OAuth stands for “Open Authorization”, which says it already: it’s about authorizing. OpenID is used for authentication. Two different concepts for two different tasks but still some sites use OAuth for authenticating purposes (it’s not (really) possible to use OpenID for authorization purposes). And this is not a “good thing” ™. In fact, quite the opposite as I will demonstrate.

An example

Suppose we want users to post comments to articles we write on our site. Let’s call this website a blog 🙂 Now, we understand that when people want to comment, they don’t want to go through the hassle of registering on yet-another-site-they-probably-never-visit-again but we certainly don’t want that everybody can comment anonymously. So using SSO could be a perfect solution. Users who have a Twitter, a Facebook or a OpenID account must be able to post comments.

How would we achieve this

Connecting with Twitter is done by OAuth. We must register our website to Twitter as an “application”. When somebody wants to authenticate with a Twitter login, OAuth will fetch a “request token” at Twitter and we will use that token to redirect the user to a Twitter login page. Once a user has logged in (or maybe that user already was logged into Twitter), it must either accept or deny the fact that our site wants to connect to their Twitter account.

Once accepted, the Twitter will return back an “accept token”, which is more or less a wildcard to do basically anything on behalf of that user, depending on the rights the user has defined (or better: the rights twitter has defined and the user has accepted). This could be doing something harmless as fetch the user profiles (is it harmless?) to even tweet out to the world with tweets like “I just commented on blog You should do too!”.  It might even be possible that our site will read and store all the public and private tweets you have made. And all you wanted to do was only using Twitter to login to our site.

So what happened here? Are we such an evil site? Well, yes and no. The problem is not so much that we do stuff like that, it’s more the fact that OAuth delegates authorizations, not authentications. After login we received our access token and for as long the token is valid (Twitter tokens don’t expire as far as I know), and the user does not retract the ticket (it’s possible, but most Twitter users don’t know how to since it’s hidden deep into the menu’s), we can do pretty much whatever we like. It’s because Twitter uses only 2 different authorization levels: read only, or read-write.

Even we use the lowest level (“read only”), we are still able to read your tweets, your profile and such and that’s not what we wanted. All we wanted is login to a site with our Twitter credentials to post a comment, not to get our Twitter account get hijacked by it.

Note that this is not OAuth’s fault. It’s just that OAuth is used for something that OAuth shouldn’t be used for to begin with.

Connecting with Facebook Connect

Facebook connect works pretty much the same way as Twitter’s OAuth implementation, but it uses more restrictions. You can say to Facebook that your site only wants to view your profile but it’s easy enough to add even more permissions. So all in all, it’s better but still the wrong tool is used for the job. We are again authorizing, not authenticating.


Now let’s try OpenID. If you have a Gmail account, Yahoo account, Livejournal or WordPress blog, you automatically have an OpenID. If you haven’t, it’s easy to create one on one of the many sites publicly available. OpenID does one thing and one thing alone: provide a 3rd party site with information about who is currently logged in (ie. authenticating). There is nothing that 3rd party site (like our site) can do on behalf of that user. When you log into our site with your account, we cannot read your (private) blog-posts, drafts, comments or even post articles onto your WordPress blog. Again: we are authenticated, not authorized.


Single sign on (SSO) is a nice system that can make the user experience for your visitors much more pleasant. However, using incorrect tools (like OAuth) for such purposes creates potential problems that users are not aware of. Of course users don’t want you to read their tweets or Facebook wall posting when they log into your site. In fact, they are doing you a favor: they went to somebody else’s registration process and they just want to post something on your site now. Leaving gaps open like this can AND WILL result in sites and applications misusing those rights and it will result in users being even more cautious on using SSO systems. A lose-lose for everybody as a result.