Kelvin wrote: > I'm a bit confused as well. > > So, does that mean the first request is made to get request token and > secret, and that's it? > > no need to do authorization and another post to get access token? > > that every request that we sign with first token and secret that's > given to us but leaving access token field empty in our data source? >
A common approach for the two-legged scenario is to issue a pre-approved access token at the point where you issue an application its consumer key. In FireEagle this is called a "General Purpose Token". Since the access token is already approved there is no need to go through the interactive part of OAuth. You can skip straight to the protected resource request. This means that when a new application is registered you would issue it four items: * Consumer Key * Consumer Secret * General Purpose OAuth Access Token * General Purpose OAuth Access Token Secret If you only ever do "two-legged", you don't even need the request token, authorization and access token endpoints. If you allow an app to act in both modes, then the application will end up with additional per-user OAuth tokens in addition to its general purpose token, with these additional tokens obtained using a traditional OAuth provisioning flow. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
