Though not OAuth 2.0 - the scenario you're describing sounds very close to that of an OpenSocial gadgets implementation - where by the open social container (which would be Analogous to your App Server) can handle relaying requests to a 3rd party API secured via OAuth - in which case it is both an OAuth provider and OAuth consumer.
Might pay to check out the OpenSocial spec, might give you some food for thought. Cheers, Alex On Thu, May 5, 2011 at 12:25 AM, Marcus Better <mar...@better.se> wrote: > Hi, > > we are implementing a service that will allow users sign in using their > account on an external OAuth 2.0 provider (a certain well-known social > network). But there is a twist: my service consists of a mobile app and > a web service. The mobile app needs to authenticate its user to the app > server, so it can access our service API and user data. > > So we have the following parties: > * Mobile App - used by end users > * App Server - provides services to the Mobile App > * Provider - OAuth 2.0 provider where users have accounts > * End User holding accounts on both the Provider and App Server. > > The requirements are: > (A) Authenticate the Mobile App to the App Server (on behalf of the end > user) to access the user data on the App Server. To simplify for end > users, they should log in using their Provider account (without separate > credentials for the App Sever). > > (B) Allow the Mobile App to access the user's protected resources at the > Provider. > > (Of course we do not consider the bad solution of asking for the user's > Provider credentials, but want to use OAuth instead.) > > Point (B) is covered by standard OAuth 2.0. > > Point (A), however, is surprisingly tricky (to me at least). I do not > know of a published OAuth flow that solves it. Is there a standard way > to do this? > > So we figured out several ways to solve this, but I'm not sure if any of > them are ideal. I'll list a few here. > > * Let the Mobile App authenticate with the Provider with the OAuth > dance, and then send the access token to the App Server. The App Server > will validate the access token, use it to identify the authenticating > user, and return a token (the same or a new one) that is authorized to > access its protected resources. > > This essentially means the App Server should be an OAuth provider itself > (or some simplified version of it). The exchange of a Provider token for > an App Server token would be accomplished with a special grant type. > > The only tricky point is how the App Server can validate the Provider > token. It seems it will have to access the Provider using the token, and > check that it succeeds. I don't like this much, because an attacker > could send lots of authentication requests to the App Server with faked > "Provider" access tokens, and the App Server would have to perform a > transaction with the Provider each time to verify the token, which could > be expensive. It would be preferable if the access token could be > validated off-line. But I don't see that OAuth provides this capability. > > * Another variation would start an OAuth dance from the client, but use > an authorization endpoint on the App Server, which would immediately > redirect to the Provider's authorization endpoint with the redirect_url > pointing back to the App Server, and finally redirect back to the > client. In this way the App Server inserts itself into the redirect > chain, and proxies the authentication request. It gets the access token > and passes it on to the client, along with any app-specific extra > parameters. From the Mobile App point of view, it uses a regular OAuth > flow with some special endpoints and parameters. > > There are other variations on this using different redirect sequences. > > Or maybe there is an entirely different solution? > > Cheers, > > Marcus > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
