Here's my take. If you are the resource owner and also the "requesting party"
operating a particular client (the classic OAuth case), you should typically be
able to visit the app that serves as the authorization server, "browse" among
the various clients that were granted access on your behalf, and revoke access
to selective clients. You can see this at work with, e.g., Twitter: While
logged in to its site, go to Settings->Apps, and you'll see all the clients
that were given access previously on your say-so. You can hit the "Revoke
access" button for any one client, which immediately revokes that client's
ability to do what it was doing before. It's up to the AS app to provide this
revocation function and to give you audit-style visibility into what that
client did; the sky's the limit, but it's not dictated by OAuth itself.
HTH!
Eve
On 19 Mar 2013, at 10:12 PM, John Smith <[email protected]> wrote:
> 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 <[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.
>
>
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.
