Skip to toolbar

Community & Business Groups

OAuth and Widgets

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:

  1. Index.html contains consumer key, and consumer secret.
  2. I add the widget’s id as part of the callback url (e.g., http://example.com/?widgetid=abc123)
  3. I used jsOAuth.js to do all the magic and get me an authentication token.
  4. I then pop up a window.
  5. I authenticate with twitter.
  6. Twitter then redirects to the callback url.
  7. 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.

6 Responses to OAuth and Widgets

  • Scott Wilson

    Another problem is distributing and protecting consumer keys and secrets, which doesn’t fit very well into a widget container kind of setup.

    Reply

  • Marcos Caceres

    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?

    Reply

  • David B. Nelson

    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.

    Reply

    • Marcos Caceres

      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.

      Reply

  • Scott Wilson

    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!

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Before you comment here, note that this forum is moderated and your IP address is sent to Akismet, the plugin we use to mitigate spam comments.

*