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
