OAuth has a "soft" assumption, which surfaces in the passage you quote among a few other places, that the resource owner is the party operating the client. I'd say the original OAuth flows made a harder assumption around this, but V2.0 is more of a framework that admits profiling delegated authorization for multiple purposes.
The User-Managed Access (UMA) profile of OAuth challenges the assumption by defining a resource owner and a requesting party, where they may or may not be identical, and then defining flows that enable a strict separation between them, including allowing the resource owner to be completely offline and unavailable when a requesting party, wielding some client app, attempts access to a protected resource. OAuth's assumption, and a way to start rectifying it, is discussed in Nat Sakimura's blog post here: http://nat.sakimura.org/2012/12/30/re-limitations-of-the-oauth-2-0-definition-of-client/ The broader implications of allowing a truly autonomous third party can be seen in this I-D, which accompanies the UMA technical spec: http://tools.ietf.org/html/draft-maler-oauth-umatrust-00 Eve On 19 Mar 2013, at 8:10 PM, John Smith <[email protected]> wrote: > Hi all, I have a question about the Oauth RFC. > > I'm reading this RFC on Oauth: > http://tools.ietf.org/html/rfc6749 > > I get to this point: > > Quote > In the traditional client-server authentication model, the client > requests an access-restricted resource (protected resource) on the > server by authenticating with the server using the resource owner's > credentials. In order to provide third-party applications access to > restricted resources, the resource owner shares its credentials with > the third party. This creates several problems and limitations: > > Who would be the resource owner in this case? The client? I see primarily 3 > parties involved: the host, the client and the 3rd party that wants what the > client has access to. > > > This is how I view this universe based on reading that paragraph. > > +--------+ +----------------+ +-----------------+ > | Client | --- > | Resource Owner | --- > | Resource Server | > +--------+ +----------------+ +-----------------+ > So, lets say that the "Resource Server" is facebook and the "Resource Owner" > is Bob (he posts pictures and greets his friends on there), but he would like > to give access to a Desktop app -- the "Client" -- to collect some metrics on > his media (the scope of this access can be defined). So, "Resource Owner" > Bob would log into "Resource Server" facebook, generate a token and paste it > into the "Client" Desktop app and have that little puppy go on its merry way. > > Is my explanation sensible? Am I missing something? > > > -- > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl -- You received this message because you are subscribed to the Google Groups "OAuth" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
