Subject: [OAUTH-WG] delegated authentication with OAuth 2.0

From: Marcus Better <[email-masked]>
Date: Wed, 04 May 2011 14:25:38 +0200

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

---

From: Alex Henderson <[email-masked]>
Date: Thu, 5 May 2011 01:17:53 +1200

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 <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 4 May 2011 07:45:38 -0700

The way we do it is by having the user authenticate through the mobile app with the app server (using an embedded browser). The app server presents the Facebook/Twitter/Yahoo login buttons and handles the authentication. After that, the app server issues the mobile app its own access token and saves the social network access token on the server.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alex Henderson
Sent: Wednesday, May 04, 2011 6:18 AM
To: Marcus Better
Cc: [email-masked]
Subject: Re: [OAUTH-WG] delegated authentication with OAuth 2.0

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

The requirements are:

Cheers,

Marcus
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Hart <[email-masked]>
Date: Wed, 4 May 2011 10:09:09 -0600

Photobucket does this with both OAuth1 (twitter) and OAuth2/WRAP (facebook,
msn messenger) services.

In the mobile app, user auth's with Photobucket.  To connect to the external
provider service, user is redirected to Photobucket to start up a session,
then to the provider service to authorize Photobucket's access.  The
callback here is Photobucket's servers again, where Photobucket stores the
tokens, and then redirects again back to the app (url handling) to signal
completion.  The app can then use an api to check on the status of those
services on Photobucket.  You can see this in action in the new Snapbucket
(Android) app, and in the existing Photobucket mobile apps on both iPhone
and Android.  The new Twitter oauth screens work a lot better on mobile than
they used to.

There's a more complicated two-app, two-server (4 legged delegation)
situation that gets yet more complicated, but I've got a draft I need to
update and submit for that :-)
----
Justin Hart
[email-masked]

On Wed, May 4, 2011 at 8:45 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> The way we do it is by having the user authenticate through the mobile app
> with the app server (using an embedded browser). The app server presents the
> Facebook/Twitter/Yahoo login buttons and handles the authentication. After
> that, the app server issues the mobile app its own access token and saves
> the social network access token on the server.
>
>
>
> EHL
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Alex Henderson
> *Sent:* Wednesday, May 04, 2011 6:18 AM
> *To:* Marcus Better
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] delegated authentication with OAuth 2.0
>
>
>

---

From: Marcus Better <[email-masked]>
Date: Wed, 04 May 2011 20:36:27 +0200

Thank you all for your advice, that was very helpful. The general
pattern seems to be similar to what I had in mind.

It would really help to have this documented properly. I would think it
is an increasingly common scenario.

Cheers,

Marcus