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 -~----------~----~----~----~------~----~------~--~---
