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

Reply via email to