If you are building a Twitter app then at some point you are going to be faced with integrating OAuth. This article summarizes my top eleven time saving tips-n-tricks. If it helps you out or if you have other tips and tricks please share your comments and ideas.
Okay so what’s OAuth? Bottom line, it’s an open protocol that gives your app special access on a user’s behalf without having to deal with storing their user name and password. So, rather than usernames and passwords, you are going to be handling tokens. You may already be thinking whoa! Aren’t I just trading one security problem with another? Sure, there are security issues with OAuth and if you search on the internet you’ll find plenty of rants about them. The bottom line is that tokens, like usernames and passwords, can also be intercepted and potentially used to access someone’s account. I address that issue below. But, if you want to build a Twitter app you are going to have to figure out the best way to implement OAuth, end of story.
Read on and let me know what you think:
- Before trying to build an Oauth library from scratch, check out ones that have already been built. It will save you a ton of time. For starters, check out this page: https://dev.twitter.com/pages/oauth_libraries
- Read Twitter’s article on “Authenticating requests with OAuth.” It’s not very long and I thought it provided a lot of very helpful information.
- Register your app at https://dev.twitter.com. If you don’t register, then OAuth transactions will not work.
- When you register your app with Twitter, on the settings page make sure the Callback URL points to an actual, functioning, domain name whether you will use it or not. It should look something like this: https://mydomainname.com/oauth.php. You’ll quickly find out you can’t specify localhost, or if you do it doesn’t work. More on that in a minute.
- If you are building a web-based Twitter app you will need to run all your requests through a proxy. In your proxy, you can override Twitter’s Callback URL parameter by setting your signature’s oauth_callback parameter (see reference section below for more info). This is especially useful for prototyping and testing when you want to use something like https://localhost/oauth/confirm.php. If don’t override the oauth_callback parameter, then you can’t use localhost for testing.
- Never ever store your Twitter consumer key or consumer secret on the client. Client apps can be de-compiled and then your secret won’t be so secret anymore. Store these on your proxy.
- Always encrypt oauth_token and oauth_token_secret when storing them on a client app.
- Use HTTPS for all oauth transactions that require a user name and password. Otherwise, this information can easily be intercepted, especially over public wi-fi.
- Twitter avatar images also require the use of a proxy. Twitter has implemented fully restrictive cross-domain polices so that web browsers can’t access these images directly. If you are getting cross-domain errors then check out this post for hints.
- Twitter’s OAuth access tokens don’t expire, although for security reasons it’s a good idea to refresh them on a regular basis. Just remember, refreshing them does involve forcing the user to re-login with Twitter.
- Twitter has a very handy online tool, called the Twurl Console, for testing out API calls via HTTP and seeing the headers and results without having to write any code. Once you have registered your application, you can find the tool here: https://dev.twitter.com/console You can also use something like Firebug or Fiddler, but they don’t have all the twitter API commands built into a pulldown list!
Just a few references:
To see a working OAuth sample app along with Flex source code and PHP proxy go here.
Oauth 1 Website: https://oauth.net/
Latest OAuth spec RFC5849: https://tools.ietf.org/html/rfc5849
Reference to the OAuth call_back parameter: See section 2.1 of RFC5849 above. To see the call_back implemention in the code sample above, look in the file EpiOAuth.php.