Subject: [OAUTH-WG] Four-legged OAuth

From: Nacho Coloma <[email-masked]>
Date: Wed, 26 Jun 2013 15:49:47 +0200

Apologies if this has been asked before, but AFAIK what I could find do not
follow the problem until a valid solution.

Let's say I have a website BookFace, which is offering services and using
OAuth2 to validate its users. For this example, it is important
that BookFace does not keep track of any users credentials, but instead
delegates into Google to provide with an authenticated user.

Now, let's say BookFace gets popular enough so that other people want to
integrate its services impersonating users. The obvious choice is
that BookFace becomes an Authorization provider itself, keeping Google as a
delegate provider. This means that we now have the following flow:

* Website X wants to "do things" and forwards to BookFace to get an access
token.
* BookFace forwards to, say, Google
* Google does its thing and returns a Google Authorization code
* BookFace exchanges the Google Authorization code for a Google Access Token
* BookFace returns a BookFace Authorization code
* Website X exchanges the BookFace Authorization code for a BookFace access
token. In the process, website X has never seen anything from Google.

This works fine, but the user has to allow permissions twice: Google asks
to approve BookFace, and BookFace asks to approve Website X. This is
confusing even for me, that as a user have to keep track of who is asking
permission to do what.

If anyone wants to experience this use case it can be done here (give it
some time to initialize on first access):
http://oauth2-client-example.appspot.com

This can be a necessary evil, but my question is if there is any initiative
in the WG to make this process less painful. In my ideal world painted with
crayons there are few authentication providers and a lot of service
providers, and this is a problem to achieve adoption.

Regards,

Nacho.

---

From: Justin Richer <[email-masked]>
Date: Wed, 26 Jun 2013 11:18:17 -0400

I think this is the only viable approach if you want to allow for 
different auth servers in different security domains. Accepting access 
tokens from somebody else's domain takes a few more steps and rules that 
the WG hasn't totally figured out yet, though some of us are working on 
the pieces (token instrospection, rules for processing/validating JWTs, 
etc.).

  -- Justin

On 06/26/2013 09:49 AM, Nacho Coloma wrote:
> Apologies if this has been asked before, but AFAIK what I could find 
> do not follow the problem until a valid solution.
>
> Let's say I have a website BookFace, which is offering services and 
> using OAuth2 to validate its users. For this example, it is important 
> that BookFace does not keep track of any users credentials, but 
> instead delegates into Google to provide with an authenticated user.
>
> Now, let's say BookFace gets popular enough so that other people want 
> to integrate its services impersonating users. The obvious choice is 
> that BookFace becomes an Authorization provider itself, keeping Google 
> as a delegate provider. This means that we now have the following flow:
>
> * Website X wants to "do things" and forwards to BookFace to get an 
> access token.
> * Website X exchanges the BookFace Authorization code for 
> a BookFace access token. In the process, website X has never seen 
> anything from Google.
>
> This works fine, but the user has to allow permissions twice: Google 
> asks to approve BookFace, and BookFace asks to approve Website X. This 
> is confusing even for me, that as a user have to keep track of who is 
> asking permission to do what.
>
> If anyone wants to experience this use case it can be done here (give 
> it some time to initialize on first access):
> <http://oauth2-client-example.appspot.com/>
>
> This can be a necessary evil, but my question is if there is any 
> initiative in the WG to make this process less painful. In my ideal 
> world painted with crayons there are few authentication providers and 
> a lot of service providers, and this is a problem to achieve adoption.
>
> Regards,
>
> Nacho.
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Vladimir Dzhuvinov / NimbusDS <[email-masked]>
Date: Wed, 26 Jun 2013 18:44:22 +0300

Hi Nacho,

The only spec that gets somewhat close to your problem of chaining
identity providers is OpenID Connect, see the section on aggregate and
distributed claims:

http://openid.net/specs/openid-connect-messages-1_0.html#AggregatedDistributedClaims

Vladimir

---

From: Nacho Coloma <[email-masked]>
Date: Wed, 26 Jun 2013 19:20:43 +0200

I was expecting to find that someone had seen this problem before and was
working towards a solution like forwarding your scopes to the delegate
authorization server to get all permissions from the user at once
(something similar to the aggregate claims in the OpenID spec, if I read it
correctly). I feel like I am alone in a corner talking about imaginary
problems, like if nobody was offering OAuth services and consuming them at
the same time.