Subject: [OAUTH-WG] OAuth2 chain flow

From: Gabriel Klein <[email-masked]>
Date: Tue, 18 Jan 2011 20:44:12 +0100

Dear oAuth2 team,

I'm currently working on the way we will implement oAuth2 in our
company. (Poken.com)

I've an interesting flow to work on:
We delegate the account creation and account authentication mechanism to
an external oAuth2 provider.

What it means:
We have a mobile application, you can choose the way you want to login.
- User and Password
- Facebook (Microsoft, Google, Twitter, and other oAuth2 provider later)
Based on the facebook access_token or code, we return a poken
access_token.

We have a similar flow in our web application (is on top of our API).

>From a technical point:
When we login using Facebook, we get the "code" or access_token (linked
to our client_id access on Facebook). This part is the responsibility of
the UI/mobile application. Facebook client_secret is not shared with
Facebook.

The mobile application then call our API. (Not implemented yet)
https://api.poken.com/oauth2/authorize?
    grant_type=poken_extenal_oauth2&
	service=facebook.com&
	service_secret={facebook_access_token or code}&
	client_id={appid-phphub}&client_secret={apppass-phphub}&
	response_type = token

In our API we exchange the facebook code for a facebook access_token and
get the facebook_account_id of the user on Facebook.

If this facebook_account_id is linked to a poken account on our system,
we return a poken access_token for this account. With this access_token,
the client can use our API.

I call this flow "oAuth2 Chain Flow"

I think it's a quite interesting flow, because it's more and more
frequent to delegate the authentication to another website/service.
(Even more when you are not part of the biggest sites.)

What do you think of this aspect of authentication?
Did you already spoke about this flow?
Do we have some specifications for this flow?

Best regards,
Gabriel Klein (poken.com)

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 18 Jan 2011 18:20:27 -0500

Interesting!  I   definitely see value in this, and... this  appears to 
me to be a new use case.

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

---

From: Justin Hart <[email-masked]>
Date: Tue, 18 Jan 2011 16:00:58 -0800

I've got a spec written for this that I've been quite lax in finishing.  I'll clean it up a bit tonight/tomorrow and send out a draft link for review.

----
-- Justin Hart
-- [email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Fri, 21 Jan 2011 10:55:09 -0700

> (Even more when you are not part of the biggest sites.)

Perhaps I don't understand all the details of your flow here but, more
generally, when resource owner authentication is delegated/federated
to another website/service, wouldn't it make sense to just allow the
authorization endpoint to authenticate via OpenID, SAML, FB, MS,
Twitter, whatever and keep OAuth agnostic to the means of
authentication?

Per http://tools.ietf.org/html/draft-ietf-oauth-v2-12#section-3.1,

"The way in which the authorization server
   authenticates the resource owner (e.g. username and password login,
   session cookies) is beyond the scope of this specification."

I believe that resource owner authentication was left out of scope
intentionally to allow for such a separation of concerns.