It’s neat when you find out people who do stuff you use and like are following your blog; in this case, I was looking through the notes for my previous post and found out digdog, the person behind iphone.gs, reblogged it.
iphone.gs is pretty much the same idea as 960.gs, except for designing websites for the iPhone, either in portrait (4 columns) or landscape (6 to 8 columns). I got to play around with it and I absolutely dig it; when I get the time, I’ll have to make good use of it. :)
Observations on Facebook's Single Sign-On Thingamajig
Yesterday at their mobile event, Facebook announced three new things for the “mobile platform”: single sign-on, full read/write APIs for Places, and a new Deals thing. What was most worrying to me about the single sign-on announcement was that very little technical details were given at the event, and that if it was implemented wrong, it would become even easier to get into people’s accounts.
These are observations I’ve made from reading the source for both the Android and iOS SDKs.
Single sign-on does not work if the Facebook app is not installed on Android, whereas it will work anywhere where multitasking is available on iOS (more on this below).
If the Facebook app is not installed on Android, it will fall back to the typical email/password form + OAuth for authentication.
Both platforms’ SSO mechanisms consist of passing an authentication request to the Facebook app, which is likely already logged into your account. The app displays the permissions dialog, and sends a token back to the original app which it uses for its API requests.
What happens to apps you’ve authorized in the past, like if you authorize an app, restore your phone, and then relaunch it? I assume that since the permissions are already given server-side, it’ll skip the permissions dialog and send you straight back to the app.
The Android SDK starts up an Intent called com.facebook.katana.ProxyAuth to handle the single sign-on process. I assume this brings up the permissions dialog directly in the app, and if the user gives your app permissions, the same authorization callback is called.
The iOS SDK uses app-specific URL handlers to pass info between apps. If the Facebook app is installed, it will launch fbauth://authorize with the same query string you’d use against the OAuth authorization page.
If your iOS device doesn’t have the Facebook app installed, it will launch the OAuth authorization page in Safari. If you’re logged into Facebook in Safari, you also benefit from single sign-on. If you are not logged in, you will get prompted to log in, making it no different from the in-app dialog you’re used to, except in Safari. In either case, you will still get redirected to the app once authorized. (This will especially benefit iPad owners, since there is no Facebook app for iPad, and running the iPhone one in 2x is horrible.)
If you are running an iOS version prior to 4.0 or are using hardware that cannot multitask, the Facebook Connect experience remains exactly the same. That does not mean it is not technically feasible to do it on older OSes or hardware; everything Facebook SSO does on the iPhone has been doable since the 2.x days, but the time it would take to switch from one app to another and back would probably amount to more time than it would take to just type your email/password into the fields.
This also means Web apps targeting the iPhone could theoretically present a “Login via the Facebook app” button and benefit from single sign-on. You couldn’t completely replace the Connect button, as there is no way to determine if any apps respond to fbauth:// URLs from MobileSafari, so if the user doesn’t have the Facebook app, they just get an error message.
You could theoretically do the same URL + querystring stuff on Android; I’m not sure if it’s there and just undocumented or if they didn’t bother because they can just call up an Intent from the app directly.
From what I can tell, all API operations, including single sign-on, are done through HTTPS.