On Dec 4, 12:57 pm, Rasmus Lerdorf <[email protected]> wrote: > Your 3-legged issue is very standard practice, is it not? A user will > authorize a client app to act on her behalf. Once that authorization > has been granted her presence is irrelevant. If she no longer wants to > allow the app to act on her behalf she can revoke the access token. >
Yes, I thought this was very straightforward too. The question was more generally, outside of the redirect scenarios described in the spec are there any other common mechanisms for this "async" situation. It's not just that the user doesn't always have to be there (duh), but is it inappropriate for the user to proactively provide the grant for the OAuth consumer to "pick up" and user later? I.e., is it appropriate to decouple their temporal proximity at the oauth provider altogether? > For 2-legged, the client app obviously has no user authorization beyond > the client's own user, so no, I would say it would be very bad form to > let it access private resources of another user. That's what I thought. > > -Rasmus > > On 12/4/10 7:29 AM, Steven Cummings wrote: > > > > > > > > > *bump*. Any thoughts on this? > > -- > > Steven > > > On Wed, Nov 3, 2010 at 2:34 PM, Steven Cummings <[email protected] > > <mailto:[email protected]>> wrote: > > > A couple of debates have come up recently within my organization. > > First, are 2-legged OAuth authorized requests allowed to access users' > > private resources? The scenario is that the application (service > > provider) has another permission model underneath that is checked for > > the client against the target resource (after the presentation of a 2- > > legged/grant_type=none access_token). My instinct is that NO, this > > isn't okay because we're basically moving the user-grant aspect of 3- > > legged into the specialized model and calling 2-legged OAuth okay for > > accessing user-private resources. Further, the spec seems to verify my > > conclusion (emphasis added by me): > > > "When the client is acting on its own behalf (**the client is also the > > resource owner**), the client does not obtain an access grant." [1] > > > Which means, the client is accessing it's own resources, not somebody > > else's. > > > The second debate, is how should OAuth be applied in 3-legged form > > when the resource owner isn't always present. This is what spawned the > > debate above. Is it okay to use that app-specific model, which the > > user previously approved, to provide authorization codes without the > > presence of th user? The scenario I'm imagining is when the 3rd-party > > app has been approved by the user to make periodic calls to either > > contribute data to the user's resources, or retrieve data from it. I > > suppose issuing refresh tokens at the time of the original approval > > would be one way to go, but if the 3rd-party misses a refresh timeout > > they're otherwise stuck waiting for user interaction again. Also, what > > if the user-approval occurs independent of the *clients* presence? > > Then the access-token grant would need to be able to say "the user > > said you could do this while you were away, and since I can auth you > > here is a token". Am I thinking about this correctly, or going about > > it the wrong way? > > > [1]http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-9 > > > -- > > 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. -- 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.
