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.