PlainOAuth now handles the easier URL callback flow in addition to PIN flow

January 31, 2011

This post is interesting to you if you’ve been following my PlainOAuth project that shows how to log in to Twitter securely from an iPhone app.

I’ve received emails and comments from several of you saying it’s been a helpful resource to understand Twitter and OAuth. Awesome.

Until now, though, PlainOAuth only supported PIN/client-based workflow. User had to tap a button to start the request, and then enter a PIN in a text field. This works fine, but is more work for user than needs be.

Twitter also supports URL-based flow, where the user just enters their username and password, but there are no PIN-s, the rest happens magically. I just pushed the change to PlainOAuth that implements this.

Note that there are a few things you must do to make sure your URL callback-based flow works.

• Switch your app type in Twitter backend from “Client” to “Browser.” According to my testing, the “Browser” app type can handle both PIN- and URL-based flows. When you pass “oob” as the callback URL to “Browser” app, it behaves as a PIN-based app. The opposite (passing a non-OOB URL to PIN-based app) yields an error.
• When instatiating TwitterLoginPopup, make sure to set its flowType to TwitterLoginCallbackFlow, and set the oAuthCallbackUrl property to the URL of your app.
• Declare in your app’s info.plist that you can handle the URL schema that you use in oAuthCallbackUrl.
• Implement application:openURL:sourceApplication:annotation: in your app delegate to receive the oauth_verifier that Twitter gives you.
• Call through to the authorizeOAuthVerifier: method of TwitterLoginPopup from your URL handler.

All of the above is demonstrated in the PlainOAuth example app.