A proposal for delegation in OAuth identity verification

For a while now, we over at the Twitter API have been touting "OAuth, OAuth, OAuth".  We really want to get people to switch over and stop using Basic Authentication when talking to our API in a production manner.  Why?  Basic Authentication is, simply, horribly insecure.  On a protocol level, unless you are using SSL to talk to our servers, all it takes is somebody tcpdump-ing some of your packets, and Base-64 decoding your Authorization header.  On an application level, it enables the password anti-pattern. There are a slew of shortcomings to OAuth and its adoption — Twitter is working to address a lot of them. 

One shortcoming that I hear a lot about is incidentally one's whose absence from OAuth is causing the password anti-pattern to persist — "identity verification delegation".  It's clearer as a concrete problem example:

You're an OAuth enabled Twitter client, and you've already authorized your user.  You user wants to use a media providing service like TwitPic.  TwitPic, currently, asks for the username and password of your user so it can store the photo on behalf of the Twitter user.  You don't have that username and password, so how do you give the ability to TwitPic to verify the identity of your user?

Effectively, how does one application pass on the ability to verify its user to another application?

We want to make it extremely easy for any site to verify a user's identity.  To that end, we're proposing an OAUth extension that will allow for this verification delegation workflow and I will be writing it up more formally in the next few days.  Until then, here is an example diagram of what this identity delegation could look like.  As stated in the problem example, I'm trying to explore the use case of an OAuth enabled client (theoretically, a future version of, Tweetie), wanting to use a third-party media provider (Twitpic, for example). TwitPic has an API method named upload that takes the username and password credentials of the Twitter user — TwitPic needs those credentials so that it can verify with Twitter the identity of this user.  In my diagram of the proposed workflow, TwitPic, after receiving the photo as part of the signed request, will verify with Twitter that the user is who he or she claims to be.

(download)

This, as you may note, is targeted towards OAuth 1.0a.  Twitter is committed to moving towards an OAuth WRAP/2.0 world, and I'll be addressing that as well — this verification delegation can be made to fit into WRAP/2.0 pretty easily.

More soon, and, of course, comments requested!
Loading mentions Retweet

Comments (10)

Feb 09, 2010
Andrew Seigner said...
Hi Raffi,

This is a great first step. To get OAuth working in our app, heypic.me, we had to use an ugly workaround. Rather than using Twitpic or Yfrog for photos, we post images to ImageShack and set them as private, so they are not browsable via the ImageShack website.

One question: I assume in the flow you describe above, the Twitter update would display as "from Tweetie", not Twitpic, correct?

Thanks and keep it up,
Andrew

Feb 09, 2010
Raffi Krikorian said...
what i've described above is about delegating identity, and not delegating actions. so, yes - twitpic would have the photo stored, and would be sure that @raffi, for example, asked to store that photo. twitpic, however, would not have any power to tweet on behalf of @raffi -- all it can do is return the URL to tweetie, who, in turn, would tweet on behalf of @raffi.
Feb 09, 2010
Mike Champion said...
Hey Raffi,

Thanks for writing this up. Couple questions:

1) Could you give an example of a PR in that example? Would it be the URL of the to-be-uploaded pic? Or just the "upload" method in general?

2) I know this is just aimed at delegating authentication, but any thoughts on delegation of authorization? Currently the basic auth handles both (although in an obviously flawed way).

Feel better!

Feb 09, 2010
Abraham Williams said...
Just a couple of thoughts...

Since TwitPic would not be posting on behalf of the user TwitPic would lose some of the natural marketing of the "from application" link. Some applications could then find it less appealing to provide APIs that support delegation.

Also if the user has already authorized TwitPic and TwitPic has access_tokens stored it could be tempting for TwitPic to post on behalf of the user. This would only happen after the verification is successful but it could cause duplicate content if Tweetie then continues to posts.

Feb 09, 2010
Raffi Krikorian said...
yes - that's definitely true.  this doesn't support twitpic's uploadAndPost method, for example.  however, in talking to a few media providers, i think they are happy that their URL is in the tweet itself -- that may be a more powerful form of marketing than the attribution line.
Feb 09, 2010
Abraham Williams said...
Regardless, it is an interesting method and I'm looking forward to trying it out.
Feb 09, 2010
Raffi Krikorian said...
the PR in this example is the "protected resource" -- in this case, it is the upload method.

i've been thinking a lot about actually delegating authorization, and we do have a solution to that (there is also the hefty recursive oauth delegation proposal).  what i wanted to really focus on was the much simpler case first, as it is probably a special case of the bigger problem?  i could be wrong, however - feel free to tell me that i am.
Feb 09, 2010
h__r__j said...
If the intention is to just delegate identity, this can be achieved more easily with what is available today:

The Consumer, prepares a verify-credentials HTTP request, signed with its OAuth token, and passes this URL to the delegator, which in turn will simply issue this request on the consumer's behalf.

Since a signed request doesn't contain the token-secrets, this is pretty safe to the consumer as well as end user.

Some more thoughts:

* Perhaps the plan is to scale this workflow to action delegation. In which case it makes sense to introduce the new flow.

* The term delegator is confusing. Shouldn't it be delegatee or something :)

Feb 09, 2010
Raffi Krikorian said...
this is a great idea, i'm going to rework around this idea.  this also fixes an issue where twitter "knows" every single API call that are being delegated.

any suggestions for a different term other than delegator?  i'm not digging delegatee.
Feb 09, 2010
Abraham Williams said...
Seems like it should just be delegate.

Leave a comment...

 
To leave a comment on this posterous, please login by clicking one of the following.
Posterous-login     twitter

About