oauth Archives - Stay N Alive

Facebook Kills Connect, Makes App Creation Easier, Simpler

As I’ve been writing Facebook Application Development for Dummies (now available on Amazon for pre-order!), there has been one thing I have been noticing: Despite all the new focus on Facebook’s Graph API, Facebook has still had a lot of conflicting focus on their old, more complicated, Connect APIs, making it a fun thing to try and explain in a Dummies book.  That confusion was evident especially in the application creation screens, where Facebook had page after page of options to fill out that they were no longer focusing on, “Widgets” to configure (which Facebook doesn’t even link to any more), and odd terminology that just doesn’t make sense any more.  Add to that the fact that, just announced, Facebook is killing the FBML versions of apps in favor of the iframe (and FBML itself in favor of Social Plugins), a lot of stuff just didn’t make sense in their app creation process any more.

2-31-e1282331313990-8908822

Some time recently it appears Facebook finally fixed that.  Now Facebook has just 5 categories to fill out when creating your application or Facebook-integrated website, and there are no confusing terms such as “Connect”, or “Widgets”, or “Canvas”.  Facebook is focusing on 5 things: “About”, “Website”, “Facebook Integration”, “Mobile”, and “Advanced”.  I think from the titles of the sections these things are obvious, and it also shows that Facebook is putting an increased focus on external use of their applications on websites and mobile and less on Facebook itself.  We also see this with the removal of custom tabs on personal profiles (they will still be available for your business Page, have no fear!).  In addition, Facebook has removed the long Application key, and is now putting focus on just the Application ID and Application Secret – this is a move they have been pushing towards since the launch of Graph API at their F8 developers conference earlier in the year.

screen-shot-2010-08-20-at-12-14-13-pm-e1282331035556-7945872
The new Facebook Application Screen is simpler and easier than the old

In addition, Facebook has added 3 experimental new features you can turn on, to focus more on their new OAuth 2.0 authentication process.  One of my biggest frustrations in trying to document all of this in my book has been the lack of consistency.  Getting graph API to handle authentication on a Facebook.com-hosted app in the past has been a horrendous experience, pretty much forcing developers back to the old way of authorization.  Now it should be easier for developers to fully focus on the new Graph API methods, both in and out of Facebook.  It is completely clear that Graph API is the future, and Social Plugins are replacing FBML (unfortunately for my second book).

screen-shot-2010-08-20-at-12-14-35-pm-e1282331174922-3452016
Facebook also added 3 new features, making OAuth 2.0 easier to manage on Canvas pages.

While frustrating as I try to adapt my book, these changes are welcome, and should make creation and configuration of apps much easier for developers in the future.  Especially with the future removal of the need to configure FBML or iFrame, along with Profile tabs, setting up an application should be a piece of cake for both novices and experienced developers alike.  I’m sure it also makes the support process for Facebook a lot easier as well.

I hope other app platforms can take Facebook’s lead on their API.  Out of all of them, Facebook’s new focus is dirt simple and easy for the most novice of programmers to learn.

Are you working on a Facebook app?  How does this affect your development on Facebook platform?

Twitter Testing "OAuth Delegation" With Select Partners – Genius

A common complaint amongst Twitter developers has been that Twitter’s OAuth, the authentication process you see when you click the Twitter login button on a 3rd party website and go to a Twitter-looking page with a “Allow” or “Deny” button, is too complicated.  Mainly, from a user experience perspective, users are required to leave the 3rd party site completely in order to log into Twitter, then get redirected back to the 3rd party site again.  If anything breaks along the way, the user is left wondering what to do, and valuable logins, purchases, or registrations could be lost.  Facebook has solved this by enabling users to do all the login process via Javascript they provide that produces a popup.  Users can log into Facebook without ever leaving the 3rd party site.  It appears, based on a thread on the Twitter developers list, that Twitter is planning to one-up Facebook by allowing users to log in to 3rd party sites without ever even needing a popup or any type of redirect, and they’re already testing it with select partners.

The topic came up when other developers noticed that the site, TwitPic.com, was allowing direct Twitter logins right on their own website and somehow posts from TwitPic were showing up with the TwitPic name and link next to the post on Twitter.  This normally isn’t possible without enabling OAuth login because Twitter has disabled the functionality for any non-OAuth produced Tweet.  In fact they have said in June of 2010 they will be completely removing the ability to login through Twitter on 3rd party sites via plain-text authentication.  So how is TwitPic doing it?

According to Raffi, an Engineer on the Twitter API platform team, Twitter is currently working on a new “OAuth Delegation” standard that will allow applications to allow users to log in via Twitter on their own sites, while still maintaining the control over Apps that OAuth gives providers and users.  So, on TwitPic, for instance, you can log in to TwitPic.com with your own Twitter username and password right on the TwitPic site itself, yet you’ll still have full control on Twitter.com to revoke access to TwitPic at any time you want to.  In addition, Twitter, at any time, can remove TwitPic’s ability to publish or access the Twitter API since they still have to use OAuth to make Twitter API calls.

If the hints in the developers list thread prove true, developers will be able to take the plaintext username and password, still store them somewhere, but in order to make calls through the Twitter API they’ll have to somehow send an OAuth key with their requests to Twitter along with some way of identifying the user.  My guess is, in essence, the app will send a one-time login on behalf of the user to Twitter (most likely via a secure SSL encryption channel or similar), and Twitter will return to the app an OAuth token to make API requests with on behalf of that user in the future.  In my opinion, this is still no different than storing an OAuth Token in a database that would give apps the same access as their Twitter username and password.

Security Concerns

While storage may be no different, I’m sure there will still be those concerned about this approach.  For instance, what happens when users get used to entering their Twitter usernames and passwords on 3rd party websites and decide to do so on a malicious website?  We’ve seen how used to entering Twitter credentials people get with websites that look like Twitter itself with the rampant phishing attacks recently.

Maybe Twitter is feeling comfortable enough that they can be proactive about such misuses and password collection.  The risk is still there though and hopefully the OAuth Delegation Twitter is getting ready to launch will cover this problem.

Partners

Thus far, it seems TwitPic is one of the partners testing this new delegation standard Twitter is working on.  Several others were mentioned in the developer discussions about this as well.  For instance, Seesmic Look is also taking similar credentials without any OAuth redirect, yet still shows the “Look” source in Tweets generated with the app.  One developer pointed out the information that could be retrieved from the new requests, and the security of it all is a little concerning.

Whatever it ends up being, the winners will be desktop and mobile client developers.  Right now developing a mobile or desktop app involves deep integration into the browser in order to legally get the user logged into the app.  It is why we see so few native desktop clients and so many AIR apps.  AIR is a browser-based solution.

I’m very interested to see what happens.  The Twitter team is supposed to announce more details very soon and I’d like to find out more about what this means for developers, how secure it is, and how much recoding I’ll have to do to enable it in my app.  Whatever it is, you can bet it will be one step simpler than the currently more-simple solution which Facebook provides.  This is getting very interesting!  Let the API wars begin…

Just in Time for the Holidays, FriendFeed Becomes First OAuth Wrap Provider

presentAbout a month ago, Facebook’s David Recordon announced that Facebook was hard at work with the Open Standards Communities on a new OAuth protocol called Wrap.  The goals of the protocol seem to specifically provide a way to direct a user through the authentication process through a client-only model, removing the need for developers to do heavy server-side code to authenticate the user.  Such a model fits well for Facebook, who, through Facebook Connect, has fought to make it as easy as possible to enable developers to authenticate users via simple Javascript and HTML.  It seems Facebook is making through with its promises, by launching FriendFeed as the first OAuth Wrap provider to launch with the new protocol.

The launch comes as a test of a discussion that took place at an OAuth Wrap Community meeting at Facebook headquarters last Tuesday, where it was discussed how to enable client-only authorization of users.  In response, Bret Taylor and the FriendFeed team (I guess, according to Luke Shepard, that means there’s still a team?) produced a working prototype of the model, enabling it on their own site.  Benjamin Golub, who was responsible for FriendFeed’s API before it was acquired by Facebook, confirmed this with the comment, “FriendFeed supports OAuth WRAP now :). Great job Bret, Luke, and David!” on FriendFeed.

Screen shot 2009-12-17 at 7.58.51 PM

It’s still unclear if this API is available to developers yet, or if it was only a proof-of-concept, but it is clear FriendFeed is very likely becoming a playground for the Facebook team to try out new technologies.  This is promising in that if this continues, FriendFeed should continue to see cool new technologies applied to it way before, and even if, they even the light of day on Facebook.com.

I’m very excited to see the Facebook team pushing these new open, client-side APIs, but even more excited to see the FriendFeed team still cranking out cool new technologies, making this the second one today for the site.  It’s becoming apparent that the FriendFeed team is finally becoming accustomed to Facebook’s internal technologies and architecture, and my hope is that we will soon to see many “beautiful butterflies” come out of what they’ve been working on over the last few months.

Now, if anyone knows how we can try this thing out I’m all ears!

UPDATE: Benjamin Golub has granted my wishes!  He says in the comments: “You can try it out yourself! Register an application at http://friendfeed.com/api/register and then follow along with http://github.com/finiteloop/friendfeed-wrap-example/blob/master/friendfeedwrap.py” – hmmm…new SocialToo feature?

Oh, the Trouble With OAuth

picture-1-6400198This article has been sitting on my desk for the past week or so, and recent activities around the Twitter/Facebook/LiveJournal/Blogger DDoS attacks have made it even more applicable, so it’s good I waited. The problem centers around the “Open” authentication protocol, OAuth, and how I believe it is keeping companies like Twitter who want to be “Open” from becoming, as they call it, “the pulse of the Internet”. The problem with OAuth is that, while it is indeed an “Open” protocol, it is neither federated, nor decentralized. We need a decentralized authentication protocol that doesn’t rely on just the likes of Twitter or Flickr or Google or Yahoo.

Let’s start by covering a little about what OAuth is. OAuth centers, as the name implies, on Authorization. This is not to be confused with identity, which other decentralized solutions like OpenID focus on. The idea behind OAuth is that any website, or “Service Provider”, will accept a certain set of HTTP requests, handle them, and send them back to the developer, or “Consumer” in exactly the same way as any other OAuth protocol does. OAuth tries to solve the issue of phishing and storage of plain-text usernames and passwords by sending the user from the Consumer website, to the Service Provider’s website to authenticate (through their own means or means such as OpenID), and then authorize. On Twitter this process is done via an “Allow” or “Deny” button the user can choose to enable an application to make API calls on their behalf. Once authorized, the Service Provider sends the user back to the Consumer’s website, which is given a series of tokens to make API calls on behalf of that user.

OAuth’s strengths are that it is easily deployable by any site that wants a central, secure, and understood authorization architecture. Any developer can deploy an OAuth instance to communicate with APIs that provide OAuth architectures because libraries have been built around the architecture for developers’ preferred programming languages, and adapting to a new site implementing OAuth is only a matter of changing a few URLs, tokens, and callback URLs. I’m afraid that’s where OAuth’s strengths end, though.

Let me just put this out there: The User Experience behind OAuth is horrible! From a user’s perspective, having to go to an entirely new website, log in, then go back to another authorization page, and then back to the originating website is quite a process for an e-commerce or web company that is focusing on sales around that user. No e-commerce company in their right mind would put their users through that process, as the sale would be lost with half the users that tried it. Not to mention the fact that (and I don’t know if this has anything to do with the actual OAuth protocol) with most OAuth implementations there is no way to customize the process the user goes through. For example, on Twitter, I can’t specify a message for my users specific to my app when they authorize it. I can’t customize it in any way to my look and feel. I completely lose control when the user leaves my site to authorize and authenticate.

Let’s add to that the problem of the iPhone, desktop apps, and other mobile apps. Sure, you can redirect the user within the app to a website to authorize, but again, you’re taking them away from the app flow during that process. It’s a pain, and headache for users to log in using that method! Not to mention they have to do that EVERY. SINGLE. TIME. they log in through your app since there’s a good chance they were not logged into Twitter or Flickr or other OAuth app in the first place. It’s a huge problem for OAuth developers on these devices, and less-than-ideal.

Now, back to my original point. The biggest problem with OAuth is that it requires a centralized architecture to properly authorize each application. We see this is a problem when entire apps like my own SocialToo.com can’t authenticate users when Twitter gets bombarded by DDoS attack. The need for centralized control of each app on their platform is understandable, in that in the end the companies implementing OAuth still need a way to “turn off” an application if an app gets out of hand. Of course, one solution to this from the developer’s (Consumer’s) perspective is to implement their own authentication and authorization scheme rather than relying on someone like Twitter’s. This is less than ideal though, since most of our users all belong to some other network that already handles this process for us. Why require our users to repeat the “account creation” process to overcome centralization?

I think there is a better solution though. What if a distributed group of “controlling sources” handled this instead, giving each company admin control over their own authorization? What I propose is that a new layer to OAuth be created (or new protocol, either way), enabling trusted “entities” to, on a peer-to-peer (federated) basis, sync authorization pools of users and their distinct permissions between each Consumer app and Service Provider. Companies/Service Providers could then register with these “controlling sources”, and they would have admin access to turn Consumer apps on or off in the event of abuse within their app.

So let’s say you’re Twitter and you want to let your developers authorize with your API. You register on one of these “controlling sources”, they confirm you’re legit (this could possibly be done via technology in some form, perhaps OpenID and FOAF), and let you create your own “domain” on the “controlling source”. Twitter would now have their own key on the “controlling source” to give developers, and the controlling source would divvy out tokens to developers wanting to access Twitter’s API. Twitter’s API could verify with the controlling source on each call that the call is legit. To kill an application, they would just need to log into the controlling source and deny the application. The application would get denied at the controlling source before it even hit Twitter’s API.

What makes this open is that, if this were itself written under an open protocol, anyone could theoretically create one of these “controlling sources”. So long as they operated under the same protocol, they would operate and work exactly the same, no matter who they were. Developers could then pick and choose what “controlling source” they wanted to authorize through. If one went down, they could switch to another. Of course, there are some security issues and authenticity of “controlling source” issues that need to be worked out, but you get the idea. This would essentially completely de-centralize the entire authorization process. Authorization itself would quickly become a federated process.

Now, that still doesn’t solve the User Experience issues I mentioned earlier. To solve those, I think we should look at Facebook and what they’re doing with Facebook Connect. With Facebook Connect, the user never leaves the Consumer’s website to authorize and authenticate. They click a button, a popup comes up, they log in, and a javascript callback notifies the app the user has been authorized and authenticated. It’s essentially a simple, 3-step process that completely leaves the website owner in control. In addition, Facebook has provided Javascript methods allowing the developer to confirm various states of authenticity, without the user having to leave the website. I’d like to see OAuth emulate this model more. Right now I’d rather implement Facebook Connect than OAuth for these reasons.

I think, as both Dave Winer and Rob Diana point out, there are some serious issues being brought up from the recent DDoS attacks against Twitter and other sites. Twitter’s inability to handle the DDoS attacks when compared to the others I think shows we need much more Federation from the site, as well as the “Open” protocols it is trying to build around. Twitter wants to become a utility. There is no way that will ever happen until they Federate, and I think that has to start with a change to the OAuth protocol.

FriendFeed Opens Up the Firehose to Developers

friendfeed-logo.jpgFriendFeed seems to be staying one (or two or three) step(s) ahead of Twitter in everything they do. Today FriendFeed released their real-time stream of data in beta to any and all developers wishing to write applications. Unlike Twitter, there is no application necessary, no NDA to sign, and all is controlled by simple OAuth. This also means users of FriendFeed-based applications will no longer need to get their special key to manually enter as was previously required.

The real-time stream is based on long-polling techniques to receive near-immediate updates of data from FriendFeed. With Long-polling, developers send a request to a given address, which the server holds open until data is ready for that request. The result is real-time data from the polled source, in this case FriendFeed. It is also less server-intensive as compared to the typical push updates similar to what Twitter is using for their /track and real-time streams, so in theory will scale better (and to me shows the maturity of the FriendFeed team as compared to Twitter’s).

In addition to their real-time stream, FriendFeed released an OAuth solution to developers, enabling users one-click access to the FriendFeed data stream for compatible apps using the platform. SocialToo, my service currently using the Twitter and Facebook platforms, will be using this authentication as well as we integrate FriendFeed into our environment. It will enable simple, one-click login and registration into our system, making it much easier for users to use socially-based applications.

My favorite addition is the integration of social graph data into the stream returned by FriendFeed. Previously, only the list of people a user subscribed to was available via the FriendFeed API. Now, both the list of those subscribed to, and those subscribed to a user are provided, enabling apps like my SocialToo to very soon be able to provide useful analytics around those following you on FriendFeed. Yes, this will also enable auto-follow and auto-unfollow (to keep out spammers) as well if users opt to do so.

Other features released in the API are the ability to upload almost any file attachment to a user’s FriendFeed stream, access to the powerful (and more than 140 character) direct message features of FriendFeed, sharing to multiple streams at once, and more. In addition, FriendFeed is returning the HTML for users and groups, so developers don’t have to differentiate between the two. Hopefully, this will also enable FriendFeed to maintain control of the API and, if you ask me, provide advertising and monetization opportunities via the API in the future as well, which Twitter has completely lost control over.

FriendFeed’s API has proven to have potential as a much more flexible option for developers than Twitter’s in the past, and I think they’re proving that with the new features. In addition to the features launched today, developers can also opt to customize the requests they send to FriendFeed, specifying query parameters about exactly what information they want to retrieve about users, allowing much smaller and much fewer requests to the platform. This is a welcome site as compared to the Twitter platform, which forces entire requests to pull information about a user and their friends, forcing much larger data requests, and higher costs for developers in the end.

FriendFeed is putting the pressure on Twitter with this release. My hope is that developers will see this, and try the platform out, giving Twitter more pressure to fix their own platform issues. If you haven’t tried it, today is the day for Social Platform developers to try FriendFeed’s API.

Social Coding: How to Code Twitter’s OAuth Using Net::OAuth and Perl

OAuthFor the non-developers in my readership, I’m going to get a little geeky on you here. So you can either tune this one out, or pass it onto your IT staff for use in their applications. I promise much more on the “Social” side here shortly. Or, maybe you’ll learn a little Perl.

For those not in the loop, my company, SocialToo.com codes in Perl, a powerful language that gives me the ability to abstract what I need at a very high level, or get down to the nitty-gritty if needed to in order to improve speed or communicate with other core Unix libraries and tools. To me, it’s a very powerful and important language that enables me to get done what I need to do without having to hire developers that know multiple languages. It’s also an amazing scripting language, and powers many of the scripts we run on the backend of SocialToo.

One of Perl’s weaknesses however is that it has never been very strong in the marketing department. For this reason, it is some times (and some times not) one of the last on the priority list for companies like Twitter when developing libraries to integrate with their API. Fortunately it has a very strong group of developers contributing to its very unique directory of open source libraries, CPAN.

Recently we launched a beta OAuth implementation on our Forgot Password page on SocialToo, which uses Twitter OAuth to identify a user and allow them to change their password based on their Twitter authentication. Fortunately with Twitter, we were able to use Net::OAuth, Perl’s OAuth libraries on CPAN, to connect with Twitter’s OAuth implementation. There were some tricks, so I’d like to share that here. It’s my hope that maybe at some point I can package this up at a much higher level to make the process even easier for Perl developers to use Twitter’s OAuth to authenticate.

Perl and OAuth – the basics

First of all, you need to understand the basic flow of the Twitter OAuth process. There are official OAuth terms for this (consumer, service provider, etc.) supposedly to make understanding the process easier, but for our purposes those terms really don’t matter. If you really want to learn more about that stuff, go over to OAuth.net and take the tutorials. What matters is that you get the Access Token you need, which you can use any time later to make requests to Twitter, such as authenticating the user, getting the user’s timeline, their profile info, friends, followers, and more. The entire goal of Twitter OAuth from a development standpoint is to get that Access Token. So here are some basic terms you need to know:

Token – a string of hashed data given to you as a unique ID to identify your application, and the user trying to use your application by Twitter. See below for the types of tokens you’ll need to get from Twitter and when.

Request Token – The token you get from Twitter before redirecting the user to authenticate with Twitter. If the user’s authentication is successful, Twitter creates an access token which identifies the user and associates them with your application. You can then access that access token later by sending another request after the user has authenticated with the request token and the request token secret key (defined below).

Request Token Secret – A string of hashed text, which only you (the developer) will ever see or use. You retrieve this when you get your Request Token, and will need to pass it with your request token when you request to get an access token. Consider this your password when trying to get an access token. Your Request Token is your ID for Twitter to identify your request with to verify the user authenticated successfully and your application has permission to access Twitter.

Access Token – Once you have your Request Token, your Request Token secret, and the user has authenticated successfully, and assuming your application has been given permission by Twitter to access the Twitter API, you can then make a request to Twitter to get your Access Token. You send Twitter your Request Token and your Request Token Secret, and the response returns your Access Token and an Access Token Secret Key for access to the Twitter API. This is a permanent key at the moment that you can use any time later. Store this in your database or a file or elsewhere once the user has authenticated and you’ll be able to authenticate on their behalf from that point on (assuming you have set your app up to do such on Twitter.com). After you have your Access Token, you can make requests to Twitter, via Net::OAuth, which perform any of the methods found via the API by sending Twitter your Access Token and Access Token Secret with the request. Use JSON::Any to parse the resulting JSON returned.

Access Token Secret – The secret key to pass with an Access Token when making API calls to Twitter. Consider this the password that goes along with the ID, which is the Access Token. Twitter looks up the Access Token ID, verifies the user is authenticated, and then checks that you also have a valid Access Token Secret Key. If both are correct and valid Twitter will send back the data you need to access the Twitter API.

Twitter Consumer Key – The unique ID of your application as identified by Twitter – you can get this in your OAuth set up on Twitter. You use this when asking for your Request Token.

Twitter Consumer Key Secret – The “password” to go with your Twitter Consumer Key when asking for your Request Token from Twitter. Twitter looks up your application by it’s ID (Consumer Key), and verifies it’s you by checking your Consumer Key Secret.

Flow of a Simple Twitter OAuth App in Perl

To understand what we’re doing, you’ll need to understand the order of things you’ll need to do in order to fully access the Twitter API through OAuth. This Flow, in plain english, should outline that process, and from here you should be able to adapt the code I provide for any use:

  1. Send a GET request to http://twitter.com/oauth/request_token asking for a request token from Twitter, and passing your appropriate Consumer Key and Consumer Key Secret to identify your application.
  2. If Twitter identifies the Application as legit (and isn’t down), parse out the request token and request token secret from the content of the returned page by Twitter. Here you’ll want to store that request token and request token secret somewhere, as you’ll need to access it again after the user returns back to your site from Twitter.
  3. Redirect to http://twitter.com/oauth/authorize, appending “?oauth_token=YOUR_REQUEST_TOKEN_GOES_HERE” to the URL, replacing YOUR_REQUEST_TOKEN_GOES_HERE with the request token you just got from Twitter. There is no need to send the Request Token secret at this point – this is simply to identify that you have received a request token from Twitter, and so Twitter can identify the user’s authentication (successful or not) with that Request Token.
  4. The user authenticates on Twitter (if not already authenticated through Twitter – if they want to authenticate through a different user they can do so here as well by logging out and re-authenticating).
  5. The user is given the option to “Allow” or “Deny” the request by the Application to access their account information on Twitter.
  6. Twitter then redirects back to the Callback URL you set up in your OAuth set up on Twitter.com – you’ll want to note this so you can write code at the location Twitter redirects to that gets the response token.
  7. Your Callback URL takes the Request Token from earlier, and Request Token Secret from earlier, and sends them to http://twitter.com/oauth/access_token to try and get an Access token. Twitter verifies that the user has authenticated successfully, that they have allowed your application to access their account, and that your Application is valid. If so, you’re returned a successful response from Twitter.
  8. You’ll want to parse out the Access Token, and Access Token Secret from the returned page, and store them somewhere with that user so you can access Twitter on their behalf later. Or, do something right then and there! You have all you need now to use the Twitter API for that user under OAuth.
  9. At this time is when I would authenticate the user if needed, making an OAuth request to access http://twitter.com/account/verify_credentials.json. To do so just send the request via Net::OAuth, along with that user’s Access Key and Access Key Secret (which hopefully you can retrieve from somewhere since you stored it somewhere earlier), and Twitter returns the data back as JSON-formatted data (or XML if you specified verify_credentials.xml) you can then parse out as necessary. You can do the same with any method in the Twitter API.

Example Code

Alright, now onto the juicy details. Assuming you’ve already set up an OAuth Twitter App under your settings tab on Twitter.com, and have your Consumer Key and Secret, you should be set to go. You’ll need to install Perl’s Net::OAuth (and any dependencies) via:

perl -MCPAN -e "install Net::OAuth"

Now, let’s get the Request Token. To do so, I’ve created a simple OAuth Accessor method to do all my OAuth handling. I use Catalyst as my MVC Framework, so all the $c and $self references refer back to the Catalyst environment. I’ll leave that up to you to figure out, or you could always try out Catalyst! So first, let’s set up this method:

=head2 oauth_request

Sends a generic request to the specified url

=cut

sub oauth_request : Private {

my $self = shift;
my $c = shift;
my $i = {
'type' => '',
'url' => '',
'extra_params' => {},
'token' => '',
'token_secret' => '',
'method' => 'GET',
@_,
};

my $request = Net::OAuth->request($i->{'type'})->new(
consumer_key => $c->config->{'twitter_consumer_key'},
consumer_secret => $c->config->{'twitter_consumer_secret'},
token => $i->{'token'},
token_secret => $i->{'token_secret'},
request_url => $i->{'url'},
request_method => $i->{'method'},
signature_method => 'HMAC-SHA1',
timestamp => time,
nonce => join('', rand_chars(size=>16, set=>'alphanumeric')),
extra_params => $i->{'extra_params'},
);

$request->sign;
$c->log->debug("URL: ".$request->to_url);

$c->log->debug("Request: ".Dumper($request));

my $ua = LWP::UserAgent->new;
my $response = '';
if ($i->{'method'} eq 'GET') {
$response = $ua->get($request->to_url);
}
else {
$response = $ua->post($request->to_url);
}
$c->log->debug("Response: ".Dumper($response));

return $response;

}

Basically, all this does is create a new Net::OAuth request object, signs it, and then sends it via a GET or POST request (via LWP) back to the specified URL. This method will handle all our OAuth requests. You’ll need to modify it to match your environment and configuration variables (like the consumer key and secret).

The token and token_secret variables can be either a request token, or access token (and secret), or neither. You won’t need to pass either when you’re trying to get your request token obviously. “type” will define what type of request it is you’re making – it can be either “request token” (to ask for a request token), “access token” (to ask for an access token), or “protected resource” (when accessing private data for a user from the Twitter API on their behalf). The “url” variable specifies the Twitter URL to request, based on the type of the request. You can get these from your OAuth settings page for your app on Twitter.com. Dont’ worry about the rest – that’s all used to generate the signature sent to Twitter with all the data you just gave it.

Now that we have that, we can make our requests to Twitter.  We’ll need to start with getting our Request Token.  We’re of course assuming this is the user’s first time authenticating through your App.  Here’s how we’ll do that using the above method:


$c->log->debug("getting request token...");

my $res = $self->oauth_request($c,
'url'       => $c->config->{'twitter_request_url'},
'type'      => "request token",
);

$c->user_session->{'oauth_redirect_url'} = uri_escape($c->req->param("redirect_url"));

if ($res->is_success) {
my $response = Net::OAuth->response('request token')->from_post_body($res->content);
if (defined $response->token) {
$c->user_session->{'request_token'} = $response->token;
$c->user_session->{'request_token_secret'} = $response->token_secret;
my $auth_url = $c->config->{'twitter_authorize_token_url'}."?oauth_token=" . $response->token;
$c->res->redirect($auth_url);
$c->detach;
return;
}
}
else {
$c->log->fatal("Something went wrong.");
# expire request tokens each time they are used
$c->user_session->{'request_token'} = '';
$c->user_session->{'request_token_secret'} = '';
}

In this example, we ask for a simple request token from Twitter to the request token URL we were given by Twitter in our OAuth settings. In this particular example (it may not be needed by yours), we allow the user to pass a redirect URL to our application via a “redirect_url” parameter in the URL. We store that in the session for later use so we can pass the user onto somewhere else if needed. You could store this in a cookie, a session, a file, or database – it’s up to you, and won’t be necessary if you never need to redirect the user later.

Assuming your app has been authorized to connect to Twitter with the Consumer Key specified, you should get a successful (200 OK) response back from Twitter. You’ll then need to parse out the Request Token and Request Token Secret keys from the response. You can do so by passing the returned content through Net::OAuth->response(‘request token’)->from_post_body() as specified.

Once you’ve got that token and a secret key for it, you’ll want to store it somewhere for later use. Twitter doesn’t give it back to your app later, so you’ll need to put it somewhere. In this example we store it in the Catalyst Session for the particular user’s session. You could store them in a cookie, session, file, or database, but you’ll need to put them somewhere. You’ll need this later.

Finally, we need to redirect the user to authenticate and authorize your App on Twitter. You send them to the authorize URL Twitter gives you in your App settings page when you set up OAuth, and append, “?oauth_token=”, followed by the Request Token you just received. Also note the error checking we do – don’t forget to cover your bases!

The user will get sent to Twitter, authenticate, and authorize your App. Finally Twitter will redirect the user back to your callback URL that you specified in your App’s settings when you set up OAuth on Twitter.com. In that URL’s logic, you’ll need to do something like the following:


$c->log->debug("request_token: ".$c->user_session->{'request_token'});
$c->log->debug("request_token_secret: ".$c->user_session->{'request_token_secret'});

my $res = $self->oauth_request($c,
'url' => $c->config->{'twitter_access_token_url'},
 'type' => "access token",
'token' => $c->user_session->{'request_token'},
'token_secret' => $c->user_session->{'request_token_secret'},
);

if ($res->is_success) {
my $response = Net::OAuth->response('access token')->from_post_body($res->content);
$c->user_session->{'access_token'} = $response->token;
$c->user_session->{'access_token_secret'} = $response->token_secret;

$c->log->debug("redirect_url: ".$c->user_session->{'oauth_redirect_url'});
$c->res->redirect(uri_unescape($c->user_session->{'oauth_redirect_url'}));
}
else {
$c->log->fatal("Could not get an Access Token: " . $res->as_string);
}

# expire request tokens each time they are used
$c->user_session->{'request_token'} = '';
$c->user_session->{'request_token_secret'} = '';

At our callback URL, our main goal now is to get that Access Token. We’re assuming the user has authenticated and approved the app. We know the request token and request token secret, but do not yet have an Access Token for the user. Let’s hope you stored the Request Token and Request Token Secret for that user somewhere. You’ll need it here.

To get the Access Token, you’ll need to send an access token request to Twitter, to the URL specified in your settings where you set up OAuth for your App on Twitter.com. In addition, you’ll want to pass into it the Request Token, and Request Token Secret we stored earlier. In this case we stored it in the session, but you’ll need to retrieve it from wherever you stored it earlier.

If your request is successful, you’ll then need to parse the Access Token and Access Token secret from Twitter by passing the returned content to the Net::OAuth->response(‘access token’)->from_post_body() method. You can then get your Access Token and Access Token Secret from the returned response, as shown in the example. You’ll then want to store those somewhere, often some place permanent to be accessed later on behalf of the user. In our specific case, since this is just a forgot password form, we only need to store it in the session for access later, which we do in the example.

Now, remember that redirect_url parameter we passed and stored in the session? Now we can retrieve that, and redirect the user wherever you intended them to go after starting the authentication process. In this case, we’ll probably pass them onto the Forgot password page for authentication verification and identification of the user. The code on the forgot password page will look something like this:


=head2 verify_credentials

Verifies the user's Twitter credentials and returns a user hashref if successful

=cut

sub verify_credentials : Private {

my ($self, $c) = @_;

if (!$c->user_session->{'access_token'}) {
return q{Access token must be retrieved from Twitter before we can run verify_credentials.};
}

my $response = $self->oauth_request($c,
'url' => 'http://twitter.com/account/verify_credentials.json',
'token' => $c->user_session->{'access_token'},
'token_secret' => $c->user_session->{'access_token_secret'},
'type' => "protected resource",
);

my $retval = '';
if ($response->is_success) {
$retval = eval { JSON::Any->jsonToObj( $response->content ) };
if ( !defined $retval ) {
return q{Twitter returned success but parsing of the response failed: }.$response->content;
}
}
else {
return $response->code;
}

return $retval;

}

In this example we simply send a protected resource request to Twitter’s verify_credentials call. We parse out the returned JSON response, and voila, we have an authenticated user and all their information! This particular method will return the full user’s data if they are authenticated. We can then use that on the forgot password form to identify who the user is, if they’re a SocialToo user, and it will work regardless if we even have their Twitter username correct, because it relies on the Twitter user id.

So, the final full code you’ll want to use will look something like this (again, I’m using the Catalyst framework):


=head2 authenticate_twitter

Redirects to Twitter to get OAuth Token

=cut

sub authenticate_twitter : Local {

my ($self, $c) = @_;

#This ensures we only run the following code the first time they authenticate - pass it ?init=1 in the "sign in to Twitter" link
unless ($c->user_session->{'request_token'} && $c->user_session->{'request_token_secret'} && !$c->req->param('init')) {
$c->log->debug("getting request token...");

my $res = $self->oauth_request($c,
'url' => $c->config->{'twitter_request_url'},
'type' => "request token",
);

$c->user_session->{'oauth_redirect_url'} = uri_escape($c->req->param("redirect_url"));

if ($res->is_success) {
my $response = Net::OAuth->response('request token')->from_post_body($res->content);
if (defined $response->token) {
$c->user_session->{'request_token'} = $response->token;
$c->user_session->{'request_token_secret'} = $response->token_secret;
my $auth_url = $c->config->{'twitter_authorize_token_url'}."?oauth_token=" . $response->token;
$c->res->redirect($auth_url);
$c->detach;
return;
}
}
else {
$c->log->fatal("Something went wrong.");
# expire request tokens each time they are used
$c->user_session->{'request_token'} = '';
$c->user_session->{'request_token_secret'} = '';
}
}
else {
$c->log->debug("request_token: ".$c->user_session->{'request_token'});
$c->log->debug("request_token_secret: ".$c->user_session->{'request_token_secret'});

my $res = $self->oauth_request($c,
'url' => $c->config->{'twitter_access_token_url'},
 'type' => "access token",
'token' => $c->user_session->{'request_token'},
'token_secret' => $c->user_session->{'request_token_secret'},
);

if ($res->is_success) {
my $response = Net::OAuth->response('access token')->from_post_body($res->content);
$c->user_session->{'access_token'} = $response->token;
$c->user_session->{'access_token_secret'} = $response->token_secret;

$c->log->debug("redirect_url: ".$c->user_session->{'oauth_redirect_url'});
$c->res->redirect(uri_unescape($c->user_session->{'oauth_redirect_url'}));
}
else {
$c->log->fatal("Could not get an Access Token: " . $res->as_string);
}

# expire request tokens each time they are used
$c->user_session->{'request_token'} = '';
$c->user_session->{'request_token_secret'} = '';
}

}

=head2 oauth_request

Sends a generic request to the specified url

=cut

sub oauth_request : Private {

my $self = shift;
my $c = shift;
my $i = {
'type' => '',
'url' => '',
'extra_params' => {},
'token' => '',
'token_secret' => '',
'method' => 'GET',
@_,
};

my $request = Net::OAuth->request($i->{'type'})->new(
consumer_key => $c->config->{'twitter_consumer_key'},
consumer_secret => $c->config->{'twitter_consumer_secret'},
token => $i->{'token'},
token_secret => $i->{'token_secret'},
request_url => $i->{'url'},
request_method => $i->{'method'},
signature_method => 'HMAC-SHA1',
timestamp => time,
nonce => join('', rand_chars(size=>16, set=>'alphanumeric')),
extra_params => $i->{'extra_params'},
);

$request->sign;
$c->log->debug("URL: ".$request->to_url);

$c->log->debug("Request: ".Dumper($request));

my $ua = LWP::UserAgent->new;
my $response = '';
if ($i->{'method'} eq 'GET') {
$response = $ua->get($request->to_url);
}
else {
$response = $ua->post($request->to_url);
}
$c->log->debug("Response: ".Dumper($response));

return $response;

}

=head2 verify_credentials

Verifies the user's Twitter credentials and returns a user hashref if successful

=cut

sub verify_credentials : Private {

my ($self, $c) = @_;

if (!$c->user_session->{'access_token'}) {
return q{Access token must be retrieved from Twitter before we can run verify_credentials.};
}

my $response = $self->oauth_request($c,
'url' => 'http://twitter.com/account/verify_credentials.json',
'token' => $c->user_session->{'access_token'},
'token_secret' => $c->user_session->{'access_token_secret'},
'type' => "protected resource",
);

my $retval = '';
if ($response->is_success) {
$retval = eval { JSON::Any->jsonToObj( $response->content ) };
if ( !defined $retval ) {
return q{Twitter returned success but parsing of the response failed: }.$response->content;
}
}
else {
return $response->code;
}

return $retval;

}

To run it, you’ll (assuming this is Catalyst) point your “Sign in With Twitter” link to /authenticate_twitter?init=1&redirect_url=http://yourdomain.com/forgot on your domain. Note that “init=1” identifies the user is not yet authenticated. That gets the request token, and redirects the user to Twitter to authenticate. Twitter then sends the user back to /authenticate_twitter on your domain. You detect that the request_token session variable has been set along with the secret key, so then run the code to get an access token. You get the access token from Twitter, store that in the session, and then redirect the user to http://yourdomain.com/forgot (identified by the redirect_url parameter in your original sign in link). http://yourdomain.com/forgot accesses the verify_credentials() method above, which takes the user session variable with the access token, verifies the user’s Twitter credentials, and returns user data for the individual. You can then display user data appropriately, and in this case allow the user to reset their password because you have officially confirmed it is them.

SocialToo Forgot Password Form

Like on Socialtoo, your forgot password form, or other OAuth instance will have a “Sign in With Twitter” link like this one that points to code similar to what I featured.

If you want to learn more, the documentation is pretty scarce at the moment. Hopefully myself or someone else will put together a much more abstract set of libraries targeting the Twitter platform soon surrounding this. I do recommend checking out OAuth.net and understanding the OAuth protocol a little more, along with the Net::OAuth documentation. Hopefully many more of you can share your experiences in the comments, or in your own blogs as you come across new experiences with Twitter’s OAuth in a Perl environment.

UPDATE: Looks like someone already has added an abstraction layer around all this. To simplify things even further, check out Net::Twitter::OAuth. It might be helpful to read this first anyway so you know what’s going on there.