Ok. I think I get it. I'll probably be asking more questions about this :) .
Basically, if I wanted to give a client access to a resource and then monitor what the client does with the resource (enters data, pulls reports, etc.), oauth would provide me a means to do this, yes? It would also allow me to grant access in certain instances based on the way the authentication server is configured, yes? On Wednesday, March 20, 2013 1:01:46 AM UTC-4, Eve Maler wrote: > > 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 <yoursurr...@gmail.com<javascript:>> > 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 oauth+un...@googlegroups.com <javascript:>. > 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 oauth+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
