OAuth and Widgets
Posted on:A little while back, I made a quick prototype showing how widgets could work with OAuth (with Twitter). The problem is that most widget engines don’t support something like Android’s Web View and usually can’t pop up Windows. Another issue is that OAuth authentication services usually use X-Frame-Options header, so that means you can’t just “popup” and iframe.
The goal was just to see what the developer experience was, what is missing, and what complexity was added (I used Chrome with Web Security turned off to get it to work like a widget). How it works:
- Index.html contains consumer key, and consumer secret.
- I add the widget’s id as part of the callback url (e.g., http://example.com/?widgetid=abc123)
- I used jsOAuth.js to do all the magic and get me an authentication token.
- I then pop up a window.
- I authenticate with twitter.
- Twitter then redirects to the callback url.
- I ‘window.opener.postMessage()‘ the access token back to the widget (yes, I know that is bad… whatever, it’s a prototype).
Costs, complexities, and security issues:
- Needed an SSL certificate ($15/year) + static IP address ($3/month). I don’t think this cost is too bad.
- As the end point of the OAuth flow (the success URL), I assumed I could not use a widget://.. so I used a real URL. A problem with widget:// is that it’s not supposed to be addressable from the outside world (supposed to be opaque).
- At the end point, I did a PostMessage() back to the “widget” sending the authorisation token … nasty town, I know. I passed the widget’s id to twitter over SSL, which I used at the end pont to target the cross-doc message.
Thinking about it, it could work like an Android URL intent filter.
Another problem is distributing and protecting consumer keys and secrets, which doesn’t fit very well into a widget container kind of setup.
Agree. Not sure how to get around this one.
How would these things normally be “protected” in a native application? For iOS apps, most of the time, I can just open a binary file with a hex editor and start searching for static strings… I can usually find everything.
If you look at the code for Angry Birds on the chrome store, they have done a pretty amazing job in obfuscating the data.
I guess my question is, is this not a general problem for all native apps?
It *is* a general problem for native apps that are openly distributed. While I’m aware of some papers on methods to obfuscate secrets in binary executable files, I’m also aware of some anecdotal reports about apparently complex schemes, deployed by well-know web services providers, being cracked in a matter of days. The recommended solution, e.g., in OAuth V2, is for the human user to authenticate and vouch for the authenticity of the application, rather than having the application posses it’s own credentials.
I also tend to feel that having a human user authenticate and vouch for the authenticity of the application is the right way to go. However, some people feel that it is too much work to have to enter in a few numbers to grant permissions.
An update to this one: Apache Wookie supports oAuth 2.0 “implicit grant”, which is supported by Facebook. This makes it possible to create Facebook widgets using oAuth 2.0 to use Facebook APIs.
So, definitely doable!