tags:

views:

74

answers:

1

Ok so I try to use OAuth (not my choice), and I don't quite understand it.

I want to access an API as a specific user. I think I need to get a token and then send it somehow... but this is very weird. I read the documentation, I get the big concept but I don't see how to actually use it.

Here are the data I have from the website I'm trying to connect to:

Consumer Key
Consumer Secret
Request Token URL
Access Token URL
Authorize Url

I must admit that I'm totally clueless, so any pointer would help.

+2  A: 

For starters, read up on http://oauth.net/core/1.0a it contains everything you need to know (at least in terms of how it all fits together - your implementation will be something you write to use the spec)

At a high level, the flow of requests would work something like this:

  • Make a request from your app to the request token URL of the provider as defined by OAuth (this includes signing generating a signature hash of the request and including it as a parameter)
  • The provider sends back an unauthorized request token - this is a single use identifier for the lifecycle of the current oauth request.
  • Your app redirects the user to the provider's Authorize URL, which is where the provider authenticates the user directly (e.g. with a login form, or by checking a cookie in the user's browser for the provider site), the provider may also ask the user to grant permission for to give access to your app for their user account
  • Assuming all goes well, the provider redirects the user back to the callback URL you provided when you first sent the user over to the provider to authenticate - they also include the original request token in the URL, as well as a new single use verification code that identifies that the request token has been authorized
  • Your app then makes a request to the provider's access token URL, passing the request token, verification code, and signing the request again.
  • The provider then checks the request token you submitted, making sure that it has been verified previously by the user, and checks that the verification code matches the one it sent back originally, and that the request token hasn't been exchanged for an access token already. The provider then sends you a shiny new access token and token secret for you to hang on to
  • Now you can actually access the provider's data - you connect to whatever web services they expose and interact with them - but you need to sign each request to prove who you are, and that the user has OKed you app to act on their behalf with the provider. The requests are include the usual OAuth params (including the access token), and are signed with the consumer secret AND the token secret.

You only have to do the request/authorize/access dance once to obtain the access token. Once you've got that, you can hang on to it (even storing it in your DB against the user), and reuse it for any future requests - until such time as the provider decides that the token has expired, or the user explicitly disables access from your app to their profile with the provider site.

phew

(Yeah, I know it's a mess, but there are libraries for most platforms to handle most of the grunt work)

madlep