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.
