OAuthapocolypse

By DigitallyBorn On August 24, 2010 · Leave a Comment

So, you’ve finally showed up, eh? Forced to stop by because all of a sudden your application that you’ve spent so many hours making work ‘just-so’ has ceased to function at all. Welcome to the club. No doubt you have many questions, the last of which is “Why is Twitterizer throwing so many exceptions?” Unfortunately for you, there will be many more questions than answers, at least for a while.

While you haven’t been paying attention, Twitter has made a large change to their API and how they handle authentication. You’re used to an authentication scheme called BASIC authentication. It’s easy and you’ve loved it. All you had to do was ask for a user’s credentials (username and password) and you were good to go. Well, I’m sorry to inform you that it will not be that easy anymore. Your immediate future is ripe with token exchanges, signed requests, and a user authentication process that will more than likely confused you for a while. Don’t worry, I’m here to help. (At least, as much as I can be.) It’s probably going to be frustrating, I only ask that you try to apply a little patience.

Very quickly, I’ll try to give you an intro into the parts of OAuth that you will need to be concerned with while migrating your application to Twitterizer2. Unfortunately, I’ll probably not do a great job of it, but I’ll try.

From now on, your application will not deal with usernames and passwords. From now on, user credentials will be expressed as access tokens. An access token consists of two values: a token value and a secret. You can think of these as a username and password that are made special for a user, but note that they will only work with your application. Speaking of, your application has it’s own credentials now in the form of a consumer token. Just like the access token, the consumer token has two values: the token and the secret. To access a user’s information, your application will need all four of these values.

“But, why, uncle Ricky?” I didn’t know we’re related! That’s so cool. Let me tell you, dearest niece and/or nephew: for security. You see, allowing users to freely share their username and password with sites is dangerous. Even if those sites are careful and trustworthy it allows users to become overly trusting until one day they play it fast and loose and drop their details with someone who isn’t quite so careful or trustworthy. We’ve all heard the story about that one guy or girl who has gotten taken by a scammer and lost it all. I know, it’s just a Twitter account, but I also know that many users have a single username/password for all of their services. If a bad guy/dirtbag/creepazoid gets his/her/its hands on those tasty bits it could lead to great trouble and I know you wouldn’t wish that on your users, so think of the greater good! Think of the children! You might as well be saving lives!

“That sounds great, but how do I get these tokens?” Getting a consumer token is easy. Just login to dev.twitter.com and register an application. Fill out the form as best as you can. Don’t worry, you can fix it later if you need to.

To get an access token for a user takes a little bit of work and a little help from the user. OAuth is designed so that the user gives you very little. Instead, they will communicate with Twitter directly. Twitter will show them information about your application, like the name you gave when you registered it, and whether or not your application will be allowed to post updates or make changes to their account. The user has the control, as they very well should: it’s their account.

Step #1: Your application will tell Twitter that you’re about to send over a user (like in red rover). When you do, Twitter will know who you are because of your consumer token. Twitter will respond with a temporary value, called a request token (that’s the last kind of token, I promise). Your application doesn’t need to remember this token for very long. Really, you should consider this like a session id. It just keeps track of a user as they go through these steps. Along with your consumer credentials, your application will send Twitter a “callback url.” (This will be explained in Step #3. No, really. It will. Just relax.)

Step #2: You send your user to a special url that includes the request token. (It’ll look like https://twitter.com/oauth/authorize?oauth_token=REQUEST-TOKEN-GOES-CHEER) If your application is a website, you should Response.Redirect them (that’s a 302 for you super-geeks). When there, Twitter will ask them to login (unless they already are), show them the particulars about your application and ask them to verify that they actually want to give you access to their goodies. If they click the obviously green “ALLOW” button, they’ll proceed to Step #3. If they chicken out and click the big red “DENY” button, they’ll disappear from your life forever (until they come back on their own).

Step #3 (for websites): The user magically appears back at your application by being redirected (again with the 302) to the “callback url” that you gave Twitter back in Step #1 (see, I told you I’d explain it). You may have forgotten who this person is .. they’ve been gone for so long. It feels like minutes! Don’t fret, my pet. They’ll have the request token (and another value called the verifier) on the querystring, just like when you sent them to Twitter. It’s right there on the querystring like an apple on a tree: all ripe with seedy, bittery goodness … just reach up and grab it. mmmm …. oh … sorry …

Step #3 (for not-websites): After the user clicks “ALLOW” the user will be given a seven digit PIN and instructed to return to your application with it in hand. Obviously, this isn’t the most ideal situation, since the user actually has to do something, but that’s life, right? You’ll just need to ask for the PIN, then proceed to Step #4.

Step #4: Your application exchanges the request token for an access token. The user has told Twitter that they want to give you the goods. Twitter has created an access token computer-hand crafted a brand new access token just for you. All you need to do now is ask for it. So, your application will send the request token (and verifier or PIN) to Twitter, and they’ll respond with your brand new, shiny access token. Not only the token, but the user’s screen name and user id, too! It’s everything you need all packaged up with a bow. From now on, you can go about your business requesting timelines and posting updates and performing searches just like before. See? That wasn’t that bad, was it!?

Some of you are still confused. That’s ok! Try not to get too frustrated by the whole thing, it takes a while for it all to sink in and I admit I’m not the best at explaining these things (although hopefully you’ve enjoyed it a little). Here are some other people’s explanations that might help you (keep in mind that other people will go into greater detail then you may need while working with Twitterizer … I do a lot of the really complicated stuff for you):