This is not a Twitter and OAuth tutorial. This post does not talk about how to use the Twitter API, nor does it offer any examples. For that, you should go elsewhere. This post simply provides a high-level overview of using an OAuth "one-time access token and secret" when you need to write a quick piece of code that fetches read-only data from the Twitter API.
You may have heard that Twitter plans to stop supporting HTTP Basic Authentication on June 30, 2010. This means that starting on June 30th, to use Twitter's API, your application must support OAuth. OAuth is a nice step up from basic authentication but it makes developing web or desktop applications that communicate with Twitter, slightly more painful. Well, painful isn't the right word, but you definitely have to jump through more hoops to get things to work. Gone are the days of simply sending a username and password to the API.
In response to this change, Twitter API proxy services like SuperTweet have popped up. Turns out, if you know what you're doing with OAuth, SuperTweet and other API proxy services are entirely unnecessary, not to mention unsafe. You're better off upgrading your applications to use OAuth the right way, instead of making them rely on potentially insecure third-party proxy services. And again, it's not difficult, just a bit annoying.
Scenario
You're a developer, and you need to write some code that pulls in Tweets from one or more users. Maybe you also need to pull down a list of followers for each of these users. Not surprisingly, it's entirely unreasonable to ask each of them to authenticate your application using OAuth. You just want to write code that pulls down their public timeline, followers, etc. avoiding the whole OAuth dance with each user, every time.
Solution
Register a new application on Twitter. Then, dig into your application control panel and find your new "single access token" and "single access token secret" for the application you just registered.
As described here, "Twitter offers the ability for you to retrieve a single access token (complete with oauth_token_secret) from application detail pages found in your application control panel. This is ideal for applications migrating to OAuth with single-user use cases ... By using a single access token, you don't need to implement the entire OAuth token acquisition dance. Instead, you can pick up from the point where you are working with an access token to make signed requests for Twitter resources."
This token and token secret is as close as you'll get to a username/password equivalent in OAuth. In other words, once you have this one-time token and token secret for your application, you can issue signed OAuth requests against the Twitter API just like you would with a basic username and password. If you want to think about it this way, the token is like your username and the token secret is like your password. Don't share them. Once you have these credentials, you can pull in Tweets for any public user, get their followers, read the public timeline, etc.
Here are several examples in a number of popular languages showing how you can use this one-time token and token secret in your project.
Yay for OAuth.
You may have heard that Twitter plans to stop supporting HTTP Basic Authentication on June 30, 2010. This means that starting on June 30th, to use Twitter's API, your application must support OAuth. OAuth is a nice step up from basic authentication but it makes developing web or desktop applications that communicate with Twitter, slightly more painful. Well, painful isn't the right word, but you definitely have to jump through more hoops to get things to work. Gone are the days of simply sending a username and password to the API.
In response to this change, Twitter API proxy services like SuperTweet have popped up. Turns out, if you know what you're doing with OAuth, SuperTweet and other API proxy services are entirely unnecessary, not to mention unsafe. You're better off upgrading your applications to use OAuth the right way, instead of making them rely on potentially insecure third-party proxy services. And again, it's not difficult, just a bit annoying.
Scenario
You're a developer, and you need to write some code that pulls in Tweets from one or more users. Maybe you also need to pull down a list of followers for each of these users. Not surprisingly, it's entirely unreasonable to ask each of them to authenticate your application using OAuth. You just want to write code that pulls down their public timeline, followers, etc. avoiding the whole OAuth dance with each user, every time.
Solution
Register a new application on Twitter. Then, dig into your application control panel and find your new "single access token" and "single access token secret" for the application you just registered.
As described here, "Twitter offers the ability for you to retrieve a single access token (complete with oauth_token_secret) from application detail pages found in your application control panel. This is ideal for applications migrating to OAuth with single-user use cases ... By using a single access token, you don't need to implement the entire OAuth token acquisition dance. Instead, you can pick up from the point where you are working with an access token to make signed requests for Twitter resources."
This token and token secret is as close as you'll get to a username/password equivalent in OAuth. In other words, once you have this one-time token and token secret for your application, you can issue signed OAuth requests against the Twitter API just like you would with a basic username and password. If you want to think about it this way, the token is like your username and the token secret is like your password. Don't share them. Once you have these credentials, you can pull in Tweets for any public user, get their followers, read the public timeline, etc.
Here are several examples in a number of popular languages showing how you can use this one-time token and token secret in your project.
Yay for OAuth.
Did you find this post helpful, or at least, interesting?