Hi! Great discussion here and very relevant to what some discussions on the IETF MMOX mailing list are heading to (MMOX is about virtual worlds but these problems might be applicable as well to social networks in general).
The main problem here is the following: A virtual worlds client wants to login a user to a certain 3D world while reusing as much of the user's data as possible. This data might be stored on various services. Services might be authentication, profile data, inventory, friends list, IM server but also 3D related services of course. All of these services can be situated anywhere on the net and we assume there is some standard API available to access that data (e.g. PortableContacts or XMPP). Now there was some talk about a service catalogue in e.g. the DiSo or DataPortability group (and probably elsewhere) which might be a simple list of where those services for a user might be located. One might e.g. use XRD as a format for this. So basically you have some user endpoint which can point you to a list of services a user has stored elsewhere on the net. This of course can be easily translated to social networks as virtual worlds might be simply be seen as the same thing but with 3D services attached. Now the requirements in MMOX might be as follows: - A user should not need to register at each virtual world to be visited as this would break the immersion - A user should be able to "carry" profile information, group memberships, inventory etc. with him This basically means that the 3D world needs to get access to many of those services listed in a service catalogue in order to function. The basics would be to have a profile available and some avatar. Now a flow could be as follows: 1. The user enters an OpenID into the virtual world client and points it to the virtual world to enter. 2. the client performs authentication as defined 3. the virtual world does service discovery on the user openid and obtains the service catalogue (XRD file) 4. the virtual world selects those service from the catalogue it needs to use and asks for authorization. Now 4. is the tricky part because you don't want to get redirected to each of these services to authorize each to give out data to that virtual world. So what's needed is some way of authorization manager to do this on behalf of the user and might result in a set of access tokens to be sent back to the virtual world to use. This might just be a basic data set the world has access to but it should then be possible for the user to add additional permissions manually later on. I am not sure I was able to explain this use case properly but I am happy to answer any questions. The main problem here is simply: How do I allow access to a set of services to a site just logged in to without being redirected to each of those. -- Christian On Sat, Apr 11, 2009 at 8:17 AM, Justin Hart <onyxra...@gmail.com> wrote: > > I've been trying to wrap my head around the situation here. > Photobucket/Tinypic have just launched Twigoo, a protocol compatible > alternative to TwitPic hosted on our servers. We don't handle login, > we use twitter to provide that, but we currently still have to at > least accept the raw twitter username/password for authentication (and > potentially queuing posts is another ball of fun). We've already > received requests to provide some method of doing uploads without > providing Twitter login/pass directly, so this is of great interest to > me. I implemented the OAuth scheme for Photobucket (essentially > written over a weekend), so I have confidence I can make something > work for Twitgoo. > > I think the immediate approach is going to be the following double- > three-legged flow (like stated in a previous message): > 1 App requests access to Twitgoo, App gets request token > 2 App directs user to Twitgoo auth endpoint > 3 Twitgoo checks if Twitter access is necessary (if authz to twitter > verified, skip to 8) > 4 Twitgoo requests access to Twitter, Twitgoo gets request token > 5 Twitgoo directs user to Twitter auth endpoint > 7 Twitter authz (potentially login screen, then authz screen) - > redirect back to Twitgoo > 8 Twitgoo gets access token from Twitter (treats as successful login, > stores on user) > 9 Twitgoo authz - redirect back to app (however specified) > 10 App gets access token from Twitgoo > > So the user could maximally see one login screen and two authorization > screens. Minimally, would see none (already logged in, already > authorized, someone just has outdated tokens). So, its adding a > second authz screen. This isn't so bad, but could confuse the heck out > of non-tech users (Though I will try to add as much good copy as > possible to explain whats going on). A user using two different apps > to connect to Twitgoo wouldn't re-auth with Twitter (it'd share the > same twitgoo-twitter token). > > A simple(ish) extension alternative may be some way of passing a > 'consumer key reliance chain' through the providers could let each one > do better messaging about whats being authorized. The flow would then > be like the first double-three-legged flow above, but potentially each > level could make specific consumer-key-chain tokens not valid with a > different chain. Could this be as simple as adding a parameter like > oauth_consumer_chain=<key>&<key>&<key>... - each level adding to > that? The keys on twice-removed layers don't mean anything to the > others, but since they're coming through a verified request from the > immediate level, you could implicitly trust the chain (?). But, > because keys on twice-removed layers don't mean anything, the > messaging still gets a little odd. That would require some central > IANA style registration for consumer IDs (not outside the realm of > possibility). > > An extension approach may be to make the requests to Twitgoo with a > second signature, based on the app's Twitter access token. (rough > example parameters) oauth_behalf_consumer oauth_behalf_token > oauth_behalf_signature (etc). where the signature is some minimal set > of the consumer token/secret, access token/secret, timestamp/nonce, > and an allowed request realm - specified by 'further' SP (allowing for > read-only, etc). > > app->twitgoo = app's consumer key/secret with twitgoo (2-legged style) > + 'behalf' paramters > - oauth_consumer, oauth_timestamp, oauth_nonce, > oauth_behalf_consumer, oauth_behalf_token, oauth_behalf_signature, > oauth_signature > - behalf signature is not verifiable by twitgoo, is intended to be > passed wholely to twitter. oauth_signature specific for twitgoo > twitgoo->twitter = twitgoo's consumer key/secret with twitter + behalf > parameters > - oauth_consumer, oauth_timestamp, oauth_nonce, > oauth_behalf_consumer, oauth_behalf_token, oauth_behalf_signature, > oauth_signature > - twitter can verify behalf signature, and twitgoo signature. > provides 'passthrough' of user's credentials. > > An issue I can see is that twitgoo could technically use the 'behalf' > parameters for any request to twitter, but that should be what the > realm parameter defines, and it is still 'rejectable' by the user, so > at least is not a plaintext password. It does provide opportunity to > the user to reject both apps independently. In the previous 'double- > three-legged' scheme, the user would only see 'twitgoo' as the > consumer app, but not the actual reuqesting app. > > This is a pretty complex case... but an interesting one, because as > more apps do 'mashup' or relying-functionality integration, the more > times OAuth is going to be put in this situation. I tend to see these > app chains much like the UNIX toolchain - each piece is small, but put > together, can make for a powerful system. > > On Mar 27, 11:53 am, Will Norris <w...@willnorris.com> wrote: > > So, given the current example scenario... > > Service - Twitter > > Primary App - Twittelator (on iPhone) > > Secondary App - TwitPic (webapp) > > > > 1) you authorize Twittelator using a normal OAuth flow on your > > phone. During the authorization step you grant Twittelator the > > ability to authorize secondary credentials on your behalf > > > > 2) Now you want to upload a photo. Twittelator sends the photo to > > TwitPic. (temporarily ignore the question of how Twittelator > > authenticates to TwitPic). TwitPic doesn't yet have a token for the > > user, so it holds the connection open with Twittelator while it goes > > and gets a request token from Twitter. TwitPic replies to Twittelator > > with a regular 302 redirect to the Twitter authorization page, just > > like a normal OAuth flow. > > > > 3) Twittelator follows the redirect to Twitter to authorize the > > token. In a standard flow, the user would authenticate to Twitter > > somehow and authorize the token. Instead, Twittelator uses its own > > OAuth access token to authenticate this request. Twitter recognizes > > that this authorization request is actually from an application and > > not a user (because it's signed with an access token). Twitter then > > verifies that the access token Twittelator is using has permission to > > authorize other tokens. It does, so Twitter authorizes TwitPic's > > request token, and returns a 302 redirect to the callback URL that was > > in the request. > > > > 4) Twittelator follows the redirect back to TwitPic. TwitPic is > > then able to exchange the request token for an access token, and post > > the picture. > > > > I'm pretty sure this should work fine, and it just adds an alternate > > authorization flow. There is of course the part I skipped over in > > step 2... how does Twittelator authenticate to TwitPic. I believe a > > basic two-legged OAuth flow would be okay here. The user doesn't need > > to authorize anything for this token, because without the access token > > TwitPic gets from Twitter, none of this really matters. > > > > Eran - given the flow you described, where Twittelator gets a > > secondary token and gives it directly to TwitPic, how is communication > > between the two applications authenticated? Would you still need the > > two legged flow there, or did my proposed flow add an additional layer > > there that wouldn't be necessary otherwise? > > > > -will > > > > On Mar 27, 2009, at 10:13 AM, Eran Hammer-Lahav wrote: > > > > > > > > > I'm not sure how this would work in practice. How would this flow be > > > triggered by the iPhone app when it wants to post a photo to > > > Twitter? And keep in mind that the user may or may not be involved > > > at this point. > > > > > EHL > > > > >> -----Original Message----- > > >> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On > > >> Behalf > > >> Of Will Norris > > >> Sent: Friday, March 27, 2009 9:35 AM > > >> To: oauth@googlegroups.com > > >> Subject: [oauth] Re: Is 4-legged OAuth possible? > > > > >> Eran, > > > > >> After reading this thread and your two posts, another approach comes > > >> to mind. In your second post, you talk about the primary application > > >> actually obtaining the oauth token for the secondary application and > > >> passing it along. But is that really necessary? All the primary > > >> application needs to be able to do is authorize a request token on > > >> behalf of the user which the secondary application has obtained. So > > >> the flow would be something like: > > > > >> - normal OAuth flow with primary application. User grants > > >> additional ability to the primary application to authorize additional > > >> tokens on the users behalf. This could of course be limited as > > >> you've > > >> described in your posts > > > > >> - secondary application gets a request token, but instead of having > > >> the user authorize the token, the primary application authorizes the > > >> token through some to-be-defined flow > > > > >> - this could work for tertiary applications in two ways. 1) the > > >> secondary application grants the token for the tertiary application. > > >> (But when/how was the secondary token granted access to authorize > > >> other tokens?) 2) if the tertiary application knows who the primary > > >> application is, it can request that the primary application authorize > > >> the token > > > > >> -will > > > > >> On Mar 27, 2009, at 9:02 AM, Eran Hammer-Lahav wrote: > > > > >>> I agree and did repeat this warning in the post. The trick of course > > >>> is to find a solution that is consistent with the simplicity of the > > >>> OAuth design. The problem with a more limited "sub" token is that > > >>> it might not be enough for the other application to perform its > > >>> activities. > > > > >>> EHL > > > > >>> Some more thoughts on this topic at > > >>http://www.hueniverse.com/hueniverse/2009/03/more-thoughts-on-oauth- > > >> access-sharing.html > > > > >>> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On > > >>> Behalf Of Mike Malone > > >>> Sent: Friday, March 27, 2009 12:57 AM > > >>> To: oauth@googlegroups.com > > >>> Subject: [oauth] Re: Is 4-legged OAuth possible? > > > > >>> 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 > > >> <e...@hueniverse.com > > >>> <mailto:e...@hueniverse.com>> 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: oauth@googlegroups.com<mailto:oauth@googlegroups.com> > > >> [mailto:oauth@googlegroups.com > > >>>> <mailto:oauth@googlegroups.com>] 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 > > > > > > > -- Christian Scholz http://mrtopf.de/blog New Podcast: http://datawithoutborders.net --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
