*bump*. Any thoughts on this? -- Steven
On Wed, Nov 3, 2010 at 2:34 PM, Steven Cummings <[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.
