I'm also interested in implementing something of similar structure as
well, though I'm not quite sure if it's actually feasible or can be
implemented with oauth at all. I'm actually quite conflicted on the
idea.
What I can see is, in this scenario, application 1 most likely has its
own set of user accounts that mirror the user accounts on the service
provider. That said, application 1's user accounts probably shouldn't
be directly linked or tightly coupled to the user accounts in the
service providers, otherwise, it seems to defeat the purpose of using
oauth to hide the actual user accounts information from the consumer.
If the user accounts are separated from the service provider (or at
least treated as such), then application 1 itself probably has to
become a service provider itself to allow application 2 to connect to
it, which means application 2 has to establish 2 different oauth
connections to both the original service provider and to application
1...
That leaves the problem of how to connect application 1 and the
service provider via application 2.

It'd be nice if OAuth can be specified to solve such problem,
something like for a consumer to connect to a distributed set of
service providers, and the service providers can inter-communicate
based on a single oauth connection.

Anyone else got other ideas?

On Jan 23, 6:28 am, nate_fish <[email protected]> wrote:
> Does OAuth support a 4 legged scenario?
>
> In this four legged scenario, there is a shared service provider,application1 
> which holds the consumer data andapplication2 which is
> trying to access data onapplication1. How would this scenario look
> to the user?
>
> My initial thought is thatapplication2 uses the OAuth 3 legged
> scenario to get access to the users data with Service Provider. They
> then use unique account id from service provider to identify user 
> withapplication1 and get authorization fromapplication1.
>
> Anyone solve for this yet or have any recommendations?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to