On Fri, Mar 27, 2009 at 7:56 AM, Mike Malone <[email protected]> wrote:
> 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... Exactly so - delegation should allow attenuation of rights to satisfy the principle of least authority. > > 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 -~----------~----~----~----~------~----~------~--~---
