How Twitter oAuth Works in Scenario Context

oAuth Scenario “Mr Twitter”

Think of authentication with Twitter as asking Mr oAuth for directions to Mr Twitters house. Mr oAuth can only give you the directions if you have permission from Mr Twitter. Also Mr oAuth is very forgetful and asks you to call Mr Twitter to ask for directions. You must call Mr Twitter to ask the directions. He asks you to leave your number and he will get back to you. He gets straight back to you with the directions and you go there. You knock on the door, then Mr Twitter answers and asks you for a password, he then gives you a key and then shuts the door. You must now use the key to open the door and while the door is open you can go in and out as much as you please. The door is self locking so if you shut the door you must use the key again to open the door. If you lose the key or if Mr Twitter takes back the key from you then you must knock again on the door and ask for a key.

Ok. So lets put this into context, in this scenario, Mr oAuth is the PHP Twitter Library for oAuth, Mr Twitter is the Twitter Application, the key is the access token and behind the door is the Twitter REST API, Mr Twitter’s House. So in order to access the Twitter REST API securely we must:

1. Getting permission to ask directions to Mr Twitters house.

This step involves creating a Twitter Developer Application to get the Consumer key and Consumer secret (permission to Ask for directions). (You must also set the access level to: Read and Write if you wish to post tweets aswell as get user info).

2. Asking Mr oAuth for directions to Mr Twitters house.

Using the two developer keys you can get an authorisation url from oAuth library (Mr Twitters phone number). You must then redirect to the url with your request token (call Mr Twitter). You can specify a callback url or use the callback specified in developer application settings (one of these must be set in order for Mr Twitter to call you back with the directions). Twitter API will then use the callback and send you a verifcation token.

3. Knocking on Mr Twitters door.

Using your verifcation token you can request an access token (knocking on the door, Mr Twitter answers and accepts your verifcation code and hands you a key, he then shuts the door).

4. Using the key to open the door.

We can use the access token to query the Twitter REST API. Also it might be handy to store the access token in PHP session variables (think of the door open as the session and if the session ends then the door closes and you must use the key again to open a new session). We can now do things securely such as posting tweets or getting user information.

Some further thoughts

Mr Twitter takes back the key – If the user “revokes” access to the application then you must go back and ask for permission again.

Saving time by storing directions in session variables (losing the key) – If the user clears thier session (loses the key) then we must request new access tokens.

Saving time by writing down the directions – We can store the oAuth tokens in a database so that we can reuse them to generate new access tokens (thus avoiding asking permission steps).