Beyond the OAuth Web Redirection Flow

(Or, How Do I Make My Desktop Applications Usable with OAuth)

There are plenty of reasons why the OAuth web redirection flow sucks. That is, the flow described in section 6 of the OAuth Core 1.0 specification. And it was all said before: it smells like phishing, it can be slow, it is hard to relay errors to the user, potential for high drop off rate, unfamiliar pattern for end users, difficulty in balancing security warnings with practical usability, requires a browser, and on and on.

But none of these are reasons not to use OAuth. They are simply challenges to overcome and a call for action to find new and better ways to authenticate users and authorize access on the web. Yes, this is a huge undertaking, but there are plenty of ways site owners can improve it today and still support OAuth. In the previous post I talked about some of the limitations of OAuth with a desktop client and the rules of rolling out an OAuth API. Now it's time for some ideas moving forward.

First, a disclaimer. I don't have all the answers. In fact, I really only have ideas. No one knows your site and your users better than you. The level of complexity and sophistication of your solution must match that of your customers, both developers and users. The ideas here are just, well, ideas. They are meant to inspire you to think outside the OAuth Core 1.0 box, not to spec out alternative workflows.

All the ideas listed here are based on the concept that while your entire API can support only OAuth, you can still provide alternative ways to get Access Tokens. That is, replace section 6 in the OAuth Core 1.0 spec with something else. Once you get an Access Token, the rest of the spec works the same.

HTTP Basic Auth to OAuth Gateway

One easy way to allow desktop applications to keep asking for a username and password is to allow them to exchange these credentials for an Access Token. Since desktop applications already have local access to practically anything, users can and should trust software they install. Giving such software their password isn’t any riskier.

A desktop application using this mechanism will ask for the username and password, then make an API call using HTTP Basic Auth (hopefully over HTTPS) and will get back an authorized Access Token. By giving their username and password to the applications, users are implicitly authorizing full access to the application anyway. Once an Access Token has been obtains, the application throws the password away and uses OAuth like everyone else.

The two advantages of this method are that the applications no longer has to save the password locally (usually in a way that is easy to extract), and that the service provider still only has to maintain a single API.

Manual Access Token Provisioning

Access Token is a terrible name to expose to end users. So let's call it something else. Guest Key, Application Token, Valet Key, etc. Instead of having applications ask for a username and password, they will ask for one of those exotic sounding things, which in fact, will be nothing more than a pre-authorized Access Token that is not bound to a specific Consumer Key (remember, those are useless in desktop applications anyway).

The user will install the application and get asked for that "Valet Key". He will log into the site and click on a button that says "Get Valet Key". The site will offer the appropriate security warnings and some information about what to do if they change their mind later, and issue the Token/Secret pair (again, hopefully over HTTPS). The user then goes and type those into the application.

So at the end, the user still types something directly into the application but at least it is not the username and password, the site gets to keep a single API, and all the other benefit of OAuth apply. This can be made even easier for users by making the token itself the username and simply generating a different password. This way, all the site has to give the user is a "guest password". Under the hood, this username/guest-password combination will be used as an Access Token.

And since there is little value in consumer credentials in this use case anyway, sites can allow users to use the same guest key for any application they install. Again, there is plenty of flexibility here for sites to pick from and adapt to their own needs and user profile.

Pending Approval Queue

Applications are usually not installed frequently. When users install a new application on their desktop or mobile device, the application can get a Request Token and stop there. Instead of asking the user to sign-in or give his credentials, the application can simply tell the user to go to the site and approve it. This of course assumes the user has access to a web browser so it might not be the best solution for adding a new application while traveling.

When the user logs into the site, some visual indication will say "You've got new applications waiting for your approval". Following that link, the screen will show which applications have been installed, when, potentially some information about the device to help the user trust the request (remember, the consumer identity cannot be fully verified), and ask the user to click approve.

The next time the user tries to use the application, it will attempt to exchange the Request Token for an Access Token. If successful, the rest of the OAuth flow is the same. If not, it will get a new Request Token and tell the user he still needs to approve it. This will require approved Request Tokens to stay in the site's database for longer than usual. But unapproved ones can be discarded after a shorter period of time, which will help keep the pending approval queue short.

Provider Facilitated Application Download

This one offers the best experience for users but is much more complex for site owners and developers. The idea is very simple. A site like Twitter can offer a page with a list of Twitter applications (remember, this is only for non web-based applications). This page will require the user to be logged in.

When the user chooses to install an application from this page, Twitter will either offer them a modified download file with an approved Access Token (and Secret) built in the download, or redirect them to the application developer with that Access Token in the redirect (again, use HTTPS). The application site can then let them download such a customized download, or package the download with another configuration file that includes the token information.

When the download is finished, the application has everything it needs to work. To solve the problem of people sharing such downloads with their friends, Twitter can use instead of an Access Token, just an approved Request Token which can only be exchanged once for an Access Token. This way, this will only work the first time the application is installed.

In addition, this methods give sites like Twitter real control over applications because they can know with a high degree of certainty which application is using a given Access Token, something that is not possible otherwise (because of the issues with consumer credentials in a desktop application).

The basic idea here is the assumption that by downloading an application while being logged-in, the user is implicitly approving access to that application. This is how Facebook applications work.

This is Just the Beginning

Once you realize that the OAuth Core 1.0 spec is really two separate mechanisms, one for obtaining an Access Token, and another for using that Access Token to make API calls, addressing usability becomes much more practical. If the redirection workflow offered by the spec is not appropriate for your customers, it should not exclude OAuth. It just means you will have to come up with some other smart ideas to supplement it.

It is absolutely critical for the OAuth community to understand this. We must accept the fact that a site choosing to use OAuth with a different Access Token flow is still welcomed and represents a successful implementation. And if some of these ideas prove to be better than others, consider standardizing them as extensions of future versions of the protocol.

These are just 4 ideas to start with. Can you come up with more?

5 thoughts on “Beyond the OAuth Web Redirection Flow

  1. These are all great ideas worth exploring more, and they’re all things we’re thinking a lot about at Plaxo. Glad to see this discussion getting more prominence, because it’s definitely the set of issues that are quickly becoming most important to getting further widespread adoption of OAuth.

  2. The biggest advantage of OAuth is the fact that the 3rd party app never gets to see your username and password for a protected resource. This is important when you are using a web site that you may not trust. It is not as critical for an app that you trust enough to install on your phone. I used an authentication scheme based on WSSE user tokens in my iphone app. See some details here: http://cherevik.com/?p=57

  3. Desktop apps don’t have it too bad. The iPhone is where web based OAuth authentification really gets messy as you can’t run your app and the browser at the same time.

Comments are closed.