gistfile1.txt

Oauth basics for JR:

The goal is to give a third party app authenticated access to your api using a token in place of a user's credentials.

To do that, the third party app first gets a consumer key and secret from your app.  These are used to sign all requests, so no other third party can pretend to be that service.

The same thing needs to happen for individual users.  Here it gets a little more complicated.  The third party app first gets a request token for that user.  This is used in all requests so we know who we're dealing with.

Once they have a request token for that user they redirect him/her to your authentication page (passing the token along in the url).  The user logs in to your app and approves the third party service.  Your app then sends them back to the third party.  At this point the third party application knows that the user is ok with giving them access to their data.

Theoretically that's all it takes, but as a security measure the user token changes when they approve the app. So the third party sends you the old token and your app returns a new authenticated one.

Using this approved token the third party service can access the user's data on your application.  Simply by sending that token and the application token.

For security all of these messages are HMACed with a secret counterpiece to each token.  Sort of like the CI cookie sessions (using a real HMAC not just a hash).