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.
On Wed, Jun 26, 2013 at 5:44 PM, Vladimir Dzhuvinov / NimbusDS < [email protected]> wrote: > 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 > > > On Wed, 2013-06-26 at 15:49 +0200, 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. > > * 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. > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
