Hi Robert, We had a session at IIW about OAuth WRAP which you probably would have found interesting.
See Section 5.1 Client Account and Password Profile in the WRAP-0.9.7.2 spec http://groups.google.com/group/oauth-wrap-wg/files This is a special 2 legged profile in WRAP in which a client gets an Access Token by submitting its consumer key (wrap_name) and consumer secret (wrap_password). Allen On 11/23/09 9:44 AM, "Robert Winch" <rwi...@gmail.com> wrote: > Allen, > > The approach you specified seems at least similar to what I attempted to > describe in the "One way I can imagine this working" scenario. The problem is > this approach appears to conflict with the Consumer Extension since access > tokens would require a non-empty string value. As Paul pointed out, the > consumer extension appears to have changed to require an empty access token. > > I would have loved to been able to attend IIW, but unfortunately I was unable. > Is there any documentation on using the session extension with two-legged > oauth that I could look at? Are there any plans to formerly specify how to do > two legged oauth with the session extension? Are there any plans to modify the > consumer extension to remove the restriction on the access token? > > Thanks in advance, > Rob > > On Sun, Nov 1, 2009 at 11:34 PM, Allen Tom <a...@yahoo-inc.com> 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 oauth@googlegroups.com >>> To unsubscribe from this group, send email to >>> oauth+unsubscr...@googlegroups.com >>> <mailto:oauth%2bunsubscr...@googlegroups.com> >>> 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 oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
