The JyMob Blog

Choose the Best People.

The OAuth Confusion and a Practical Workaround

I am no security expert, but I understand that there is a marked difference between authentication and authorization, just like any average web user does. We need a way to separate the mechanism that identifies someone from the mechanism that decides what s/he can do. Thus, it is obvious that authentication comes first and then authorization. Most of the websites you visit need a way to permanently identify you. And they do that by making you create user name and password. This of course results is creating easy-to-crack passwords if the website makes you create a user name and password. This is because there are just so many of them! Creating a password, maintaining it is really a nightmare.

OpenID came along and it said that let us delegate the act of identifying someone to a few trusted sources. These are the so called OpenID providers. For example, Yahoo! is an OpenID provider. We trust them and they identify us through our Yahoo! profile. Then a new website which becomes an OpenID consumer delegates the identity determination to Yahoo! To this new website, you are user joe on Yahoo! and they know you that way.

This was just on the brink of getting over an average user’s understanding and then came along OAuth, not in one but two versions. And they said that, well, we are here to solve your problem of who can do what. At the same time, something supposedly very important happened – the rise of the social networks. It’s an undeniable fact that social networks are a reality and so is the e-commerce. Your needs to let one website access your data stored on another website increased. For instance, suppose all my photos are on Flickr and I want a certain website, Printr to print them out for me. Now, instead of uploading them again at Printr’s website, I can let it access my Flickr photos. It’s deemed convenient by most of the users. Note however that while I do so, I have to identify to Printr that I am who I say I am on Flickr.

To me, this is like delegation of identity. In authorizing Printr to access your Flickr photos, you had to somehow prove to Printr your Flickr identity! So, in my opinion, OAuth can be extended to provide the necessary identity. Thus, for Printr I am not joe, but joe@Flickr, which is fine. Printr does not have to insist on making me create an account (that works only) on Printr’s website. It’s fine if Printr prompts me for my email address and Flickr (, or my access settings on Flickr) refuses to reveal that during the Printr-Flickr negotiation phase.

In other words, you, as a website developer, have to make a choice – whether to use Facebook or LinkedIn credentials as a means of establishing identity (along with an optional user name and password screen and of course, OpenID). In my opinion, it is fine. Since odds are that Facebook et. al. are going to outlast your website and that we, as a human race, seem to have already committed to them, I see no problem in having such delegated identity establishment. What is really worse is have a Facebook Connect, a Twitter Login and also make the user pick a password. (Yes, there are websites that do that).

I am sure there will be some corner cases where this would be a problem. But then dare I say that it will be an uncommon case. To make common case suffer because of that is not a good design choice.