OAuth Echo - delegation in identity verification

Attached is an example workflow diagram for OAuth Echo — what I'm now calling the delegation for identity verification workflow (thanks to @joestump for the name).  This diagram is the latest evolution from take 1 and take 2.  

What's delegation in identity verification?  To re-state the problem:

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?

From all the comments I've received so far, I've broken this problem up into two:
  • OAuth Echo - plain and vanilla identity verification delegation - this is the version that Twitter is most likely to implement and advocate; and
  • OAuth Echo Restricted - adding some security restrictions around OAuth Echo to ensure that an identity verification delegation request can only occur through a named and specific Delegator
OAuth Echo is detailed on page one, and it's really elegant and simple — you, as the Consumer, make a call on a protected resource.  As part of that call, you also give that Delegator the Authorization header needed so that the Delegator can make an OAuth call to  account/verifiy_credentials on Twitter to confirm the identity of the user.

The Restricted version has the Consumer "name" the Delegator he or she is using as part of the request, and include that name in the signed Authorization header that the Consumer has passed along. The Delegator then takes that data, re-signs it, and passes it along to Twitter.  Twitter can then verify the Delegator, can verify the Authorization header as being signed by the user (using the Consumer), can verify that the user (and Consumer) have asked for it to be sent via that particular Delegator, and then confirm everything.

(download)

Again, once I feel that this has been settled down, I'll write this up more formally and also port it to OAuth WRAP/2.0.

Thanks for all the comments so far!
Loading mentions Retweet

Comments (8)

Feb 11, 2010
mynetx said...
Well, #OAuth Echo Restricted is cool and all, but who sets x_delegator and makes sure they’re all unique?
Feb 11, 2010
Abraham Williams said...
The service provider. In this example it would be Twitter through the Oauth application registration process.
Feb 11, 2010
mbetter said...
In the workflow, it looks like steps 2 and 3 have to be executed while the request in step 1 is waiting (so that an appropriate status code can be returned). D will have to receive and store a potentially large amount of data (the picture) throughout the verification transaction. That could open up DoS and scalability issues.

It would be preferable to let C request a token from D in a preliminary step, which would perform identity verification. The upload of the image data would happen in a second request, containing that token.

Actually this would make the workflow closer to plain OAuth, which might be a good idea in itself.

Feb 11, 2010
Abraham Williams said...
It would be interesting to have D essentially issuing it's own access tokens for identities. This could be an extension for larger sites that have to manpower to implement it. I don't like how it would make the process more complicated though. The current flow is nice and simple.
Feb 11, 2010
mbetter said...
By staying closer to current OAuth workflows instead of inventing new ones ad hoc, we may get something slightly more complex, but also get to re-use an architecture which has proven itself in the field and had a lot of thought put into it. It would also be possible to re-use much of existing OAuth server code (for D).

The general problem with this approach is this: We want to delegate authentication (identity verification). In OAuth, identity verification is done only once, when binding an identity to a token. It is separate from authorization for each subsequent secure request. This proposal collapses these two concepts.

Because of this, every request to a protected resource (C to D) requires a verify request from D to SP (since a new Authorization header has to be sent each time, with a new nonce). If C makes many such requests, which is quite plausible, there will be lots of unnecessary traffic to SP.

Clearly the one-time authentication is the only step in OAuth that needs to be delegated. This should only require a minimal change to OAuth, instead of a new workflow.

Feb 11, 2010
Raffi Krikorian said...
in this case, i'm envisioning that Twitter (or the service provider) would make sure its unique. for example, when an application registers with Twitter, they provide us with a unique name that we associate with that application.  

when an application wants to use oauth echo restricted, they need to find out what the Delegator's unique name is (the Delegator would know, and can publish it), and then set x_delegator to that.

Feb 11, 2010
Raffi Krikorian said...
this is definitely interesting.  oauth echo was designed looking at the current TwitPic API -- in that API, you pass a username and a password along with your call that uploads a photo.  
  • if implementing the upload endpoint, then you have to hold onto the photo until you can verify with Twitter, using the username and password.  if Twitter can't verify it, then you may have to delete the photo; and
  • if implementing the uploadAndPost endpoint, the its a similar problem.  the photo needs to be held onto while the API implementor attempts to post a status update on Twitter.  if that status update fails, then the photo will be deleted
all this should happen synchronously with the call to the endpoint.  

that all being said, let me explore a third option which involves getting a token from D that can be re-used by C.  this may be more of an authorization profile, however?
Feb 12, 2010
Abraham Williams said...
Services like bit.ly could use this instead of having you enter their API token manually into the application you are using.

Leave a comment...

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

About