OAuth — a proposed Open Authentication standard — fills a significant gap in cross-application authentication. It’s common in a world of myriad web-based services for one service you use to want to access another service you use, in order to make things better or easier for you.

For example, you might keep contacts in your mail service, and you might want your photo service to see if people you’re in contact with have photos that you might share. We’ve generally done that sort of thing in one of two ways:

1. Manual: you go to your mail service and tell it to “export” your contacts to a file on your computer, and then you go to your photo service and tell it to “import” contacts from that file.
2. Automatic: you give your user name and password for your mail service to the photo service, and it logs in and reads your contacts directly.

It should be pretty clear that the manual mechanism is annoying — perhaps to the point of being infeasible for inexperienced users (the “Barry’s mother problem”) — and that the automatic mechanism is risky, handing your login credentials over to someone else. You might trust your photo service, but what if there’s a problem that results in your email login credentials getting stolen?

Some folks developed an alternative mechanism, called OAuth. Essentially, it works like this, in the example case above:

1. While you’re using your photo service, you click a link that says something like “See if your contacts have anything to share.”
2. The photo service redirects your browser to your mail service and tells it what it wants to do.
3. Your mail service shows you a screen asking you to approve the action.
4. If you approve it, your browser is given a token, and is redirected back to the photo service.
5. Your browser gives the token to the photo service, which uses it to connect to your mail service and retrieve your contact list.
6. Your photo service shows you the shared photos from your contacts, just as you wanted.

The advantages of this scheme are:

1. It’s simple for you; you just click on the “Do this for me,” link on one service, see the approval screen from the other service, then see the result of the action back on the first service.
2. You can verify that the intermediate approval screen is legitimate, because all the security indicators work. The screen really does come from the second service (the mail service, here), and you interact with it directly.
3. Your login credentials are only sent to the service you’re logging into, and are never give to anyone else.
4. You authorize only the actions needed by the requesting service, and no more. If you give away your credentials, the recipient can do anything. But with OAuth, you can authorize the photo service to read (and not change) your contact list, but not your mail. You can authorize a “send to a friend” service to send email on your behalf just once, but not to read your existing mail. And you can authorize an archive service to read your mail always, but not allow it to send mail.

The only problem with the system involves presenting you with an approval screen that makes sense to you, and making sure that you don’t approve something you shouldn’t (or don’t mean to). Let’s look at that:

In this example, the approval screen should say something like this:

The Frobozz Photo Service would like read access to your contacts. Do you approve this request?

Yes        No

But suppose, instead, that the photo service asked for more access than it needed, either carelessly or, perhaps, maliciously. Suppose you got an approval message like this:

The Frobozz Photo Service would like full access to your contacts. Do you approve this request?

Yes        No

Or like this:

The Frobozz Photo Service would like full access to your account. Do you approve this request?

Yes        No

Would you realize that there was something wrong? Would you know it was asking for more access than it needed? Would you say “No”? Would my mother?

At the recent IETF meeting, I brought this up with the OAuth chairs, Area Directors, and others, and stressed that a key part of making OAuth work is getting the user interfaces right, and that we can’t leave that to arbitrary implementations. Even though the IETF doesn’t usually do user interfaces, in this case the UI is an integral part of the security of the system. We need a document that lays this out and makes it clear what the potential problems are, perhaps working with UI experts and giving advice on ways to handle it (and ways not to).

And today, the folks at F-Secure point out a case in the wild. Twitter has been using OAuth for a while, and now requires it as the only way applications can get access to Twitter accounts. That’s good, but see this real example:

Is the person who clicked on whatever caused this...

1. ...expecting such an authorization request?
2. ...aware of what it means to approve access and update authorization?

Would that person know enough to say “Deny”? A great many Internet users — perhaps the majority — are not aware, and would choose “Allow”, giving their Twitter account over to a spammer, just because they happen to like Lady Gaga and think that this is associated with her, and perhaps that it will give them access to her tweets, music, videos, or whatever.

F-Secure wants a quick way to rescind the authorization, once the victim realizes what’s happening, and that’s a fine demand. Yet, would most users even make the connection between their granting of this authorization for “Lady Gaga” and the appearance of unrelated spam tweets from their own Twitter accounts? Would they even know what they should rescind, even if they knew that they could (and how)? I doubt it.

As good an idea as OAuth is, this is a real sticking point. We have no idea how to solve it, but we must try.