Good post, Eran, but if you removed the token/consumer matching requirement entirely, and encouraged sharing token credentials, wouldn't we essentially be in the same boat we're currently in with usernames and passwords? (Ok, that may be a bit of an exaggeration, but we'd still be giving up a lot of what makes OAuth secure.)
What if an application could request a limited use token (limited permissions, limited number of requests, limited lifetime, etc.) that it could then pass on to a third party application to make requests? Just a thought... Mike On Fri, Mar 27, 2009 at 12:28 AM, Eran Hammer-Lahav <[email protected]>wrote: > > First, let's now get carried away with the leg count... I don't think > naming this scenario 4-legged is helpful. > > I think your use case could be addressed in many way and the complexity > level should be based on the actual threat model, not some generic > "requirements". > > You'll notice that while section 6.3.2 (Core 1.0) explicitly requires that > "The Request Token matches the Consumer Key", there is no such requirement > in section 7. This means clients are free to share the token credentials > with other clients if permitted by the server. > > This is a question of managing expectations more than anything else (when a > user authorizes an application, they usually have an idea of what the > application is going to do, including using other applications). I would > encourage servers to permit token usage by clients other than those the > tokens were issued to, only after explicitly obtaining permission for that > from the client. > > While it would be great to have a way to keep the chain of control active > for sharing access, services like Twitter might be just fine with just > allowing tokens to be shared between applications. > > EHL > > More thought on my blog > http://www.hueniverse.com/hueniverse/2009/03/taking-oauth-beyond-the-3rd-leg.html > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf > > Of Ivan Kirigin > > Sent: Wednesday, March 25, 2009 9:14 AM > > To: OAuth > > Subject: [oauth] Is 4-legged OAuth possible? > > > > > > Hi, > > > > I recently integrated Twitter's OAuth into my site, http://tipjoy.com > > > > It's a great user experience and a lot like Facebook Connect. > > > > But I ran into a problem when developing our API for Twitter > > applications to use Tipjoy for payments. OAuth tokens aren't > > transferable like a username & password. For example, a Twitter user > > on TweetDeck can input a username & password, which lets TweetDeck > > post a picture to TwitPic. If TweetDeck were granted OAuth access to > > the user's Twitter account, TwitPic couldn't verify the access tokens > > easily, and couldn't communicate to Twitter with them. > > > > How can we power this 4-legged OAuth? Twitter could act as an > > intermediary, to tell TwitPic that the request from TweetDeck is > > authorized. > > > > I'm told Facebook is coming up with a solution for Facebook Connect. > > As the environment for social apps becomes more connected, this > > communication between 3rd parties about users on the OAuth provider > > become more important. > > > > What do you all think? > > > > Thanks, > > Ivan > > http://tipjoy.com > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
