Apparently the requirement for an empty oauth_token was added in the second draft of the OAuth Consumer Request Extension? What was the reasoning behind this?
Is not the Request Token request not a Consumer resource? Does it not seem any different than any other resource meant to be addressed by the Consumer Request Extension? As there is no oauth_token in the request for a Request Token, does it not make sense to keep consistency? I think an argument can be made to include the Consumer Request Extension should be part of core OAuth to address all SP API resources that are not End User related (including the Request Token resource). Paul On Nov 1, 2009, at 9:34 PM, Allen Tom wrote: > > Hi Robert, > > This is actually a very good question. One possible approach would be > for the Consumer obtain a 2 legged Access Token by submitting its > Consumer Key and Secret (or signature) to the SP's authentication > service. The auth service will return a 2 legged access token (and > access token secret) that can then be used for 2 legged requests. > > When the access token expires, the consumer can get a new one by > repeating the process from the beginning. > > If you're going to be at IIW, representatives from Microsoft (Dick > Hardt), Yahoo (me), and Google (Brian Eaton) will be giving a > session on > Thursday about exactly this use case. > > Allen > > > Robert Winch wrote: >> Sorry to keep at this, but I am attempting to figure out the best way >> to go about doing 2-Legged OAuth with the Session Extension. My goal >> is still the same in that I wish to avoid using a database to >> validate >> requests. I also would like credentials to be short lived. Both of >> these goals can be achieved with the Session Extension for 3-Legged >> cases, but my requirements do not always involve the User. Thus I am >> trying to see how OAuth Session Extension should work with 2-Legged >> OAuth. The fundamental problem I am having is that the consumer >> extension states that requests to protected resources the oauth_token >> must be an empty string [1]. This seems to conflict with the way that >> the OAuth Session Extension works. >> >> One way I can imagine this working is to follow the OAuth Session >> Extension flow except it would skip steps involving the request >> token. >> When requesting an access token, the Consumer would specify an empty >> string for the value of request token (oauth_token) indicating it is >> 2-Legged. The Consumer would then follow the normal flow of using >> that >> Access Token to request protected resources. The problem is that the >> oauth_token would contain a value and thus it would not be following >> the consumer extension. >> >> As I alluded to, I can think of someways of achieving this. >> However, I >> would like to follow the specs as closely as possible in order to >> gain >> all the benefits that come with following specifications. I am still >> rather new to OAuth, so I am hoping someone can point out something >> that I am missing. Can anyone help me to solve this problem in a >> manner that is defined by the specifications? >> >> Thanks in advance, >> Rob >> >> [1] >> http://oauth.googlecode.com/svn/spec/ext/consumer_request/1.0/drafts/2/spec.html#anchor4 >> >>> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
