OAuth isn’t (Always) the Solution

Don’t get we wrong, OAuth is great, or at least I hope it will be considering the number of hours I put in this week into getting the spec ready for prime time. But I’ve been hearing a lot of chatter lately on what OAuth is good for and some of it makes little sense to me. I don’t want to point at specific examples as some of them come from people I truly admire, but they are there. At the Data Sharing Summit, OAuth was thrown into the mix of solutions to problems it had nothing to do with.

OAuth at the DMV

OAuth is perfect for any case where you don’t want to give your username and password, but instead wants to give something else you can revoke at any time, that will give another site limited access to your stuff. I have been busy the past couple of nights writing a new complete OAuth example for the spec. It begins something like this:

In this example, the Service Provider photos.example.com is a photo sharing website, and the Consumer printer.example.com is a photo printing website. Jane, the User, would like printer.example.com to print the private photo `vacation.jpg` stored at photos.example.com.

When Jane signs-into photos.example.com using her username and password, she can access the photo by going to the URL `http://photos.example.com/file=vacation.jpg`. Other Users cannot access that photo, and Jane does not want to share her username and password with printer.example.com.

For me, this is the ultimate example. Where are some places OAuth doesn’t belong? To start with, at the Service Provider. This might sound obvious but it is not (to some people). Another test is if OAuth makes life more difficult. If you currently just enter a username and password into some application, but will now have to go through a whole bunch of steps, screens, and prompts, it probably means they shouldn’t have used OAuth.

OAuth replaces one dialog for username and password (which is the typical credential set – OAuth does not mention usernames and password specifically) with 2 dialogs: one for username and password, and another for asking you if you want to give some site access to you private stuff. That’s it. If you read OAuth and think it is perfect for what you are doing, ask yourself if you will be able to stick to this simple flow – if not you might be using the wrong tool.

The one place OAuth does not belong but should be anyway is the DMV! It will not make things better but you’ll know the steps to that dance.

‘OAuth at the DMV’ was written by me, created by Christopher Carrasco.

8 thoughts on “OAuth isn’t (Always) the Solution

  1. I’ve been asked to give some examples of incorrect OAuth usage:
    1. The Consumer is the Service Provider website. Someone suggested to improve their website by supporting OAuth. They will be hiding their own users’ credentials from themselves.
    2. Many examples of API interop. Twitter connecting to Pownce for sharing followers and updates (internally, not on behalf of a user) is a common example.
    3. General server to server examples where the user isn’t involve. If there is no user, OAuth doesn’t belong there.

  2. In response to 3: do not the digital signing specifications provide value in server to server scenarios?

  3. You can use the signature workflow for other things such as server to server (which is the case in exchanging tokens for example). But that is just a subset of the protocol. Also, you will need to use SSL for the token exchange to really make it secure, and in that case you might as well just use SSL alone for all calls.
    The power of OAuth is the way the user interact with the two sites, the Service Provider and Consumer. There are a lot of smart ideas in there which you can use, but as a whole, if there is no user, it doesn’t really apply.

  4. I have a question. I’m hosting weblogs for my customers (A). Now I’m making a deal with a storage provider (B). He deals with file uploads, quota etc. He doesn’t know my customers. I can give him a storage-name for every of my customers. Thing is, he allows uploads only for my customers. My Idea is: logged in (A) customers see a link to B. B redirects them to A, with a request for access. Since they are logged in, no login pages/ allow to give access pages are provided. A redirects back to B with OK and the storage-name parameter. The customer can now upload stuff here. Server to server communication is via an external protocol (list files, delete files etc.)
    Do you think, this is a valid case for using OAuth?

  5. What you describe is a two way scenario in which your site is an OAuth provider where the resource is identity, and the remote site is an OAuth provider where the resource is file storage. This will work but might be a bit complex. Another approach is for your site to support OpenID as a provider and the storage site to accept OpenID as a relaying party.

Comments are closed.