Allowing third party access to your users’ data

September 30, 2006

I was driving home from PHP Appalachia the other day and was thinking about how web services and web APIs in general are somewhat limiting. I’ve had some discussions with David at our local tripug.org group, and his company is currently putting together an API for their customers to use. He’s facing a lot of decisions to make in building that, but I’m confident they’ll ultimately do a good job of it. That was probably a bit of a tangent, but it crossed my mind as I was thinking of flickr and other similar web-based services that ultimately hold a lot of your data. We’d talked about (ah yes, that’s why it crossed my mind) the issues of the various web services offering different ways of authenticating external apps through their APIs.

One of the key drawbacks *seems* to be that for most systems, I have to give my username/password to an application to then connect on my behalf. I was putting together a blog publishing system some months back and wanted to be able to connect to various services (blogger, livejournal, xanga, wordpress, etc) to publish from one source (my app). The frustration I had was enormous because all the services were so grounded in ‘years ago’ thinking (yes, I’m getting on a high horse here) but they all required my app to connect with the direct username/password of the author’s blog - effectively, my service had to *become* that person. Ben Ramsey discussed a similar project he was thinking of doing and came across the same inherent limitation.

So, on the drive home I was thinking that the key is having multiple authenticated accounts associated with a main account which are allowed discrete leves of access (read/write/edit/whatever) to discrete islands of data (everything/only archive data/etc). In actuality, this was something that had crossed my mind about a year or so ago, but it wasn’t anything I bothered to write about. Frankly, I’m not sure I could even articulate it as well as I just did above, and I know I didn’t even do a great job there! Let me try again, with a concrete ‘possibility’ example…

My wordpress blog has an area in the control panel for ‘3rd party access’. There I can describe which third party apps have access to read/contribute/edit/delete posts or comments on my blog. A third party app ‘permission request’ would be lodged when I or someone else hit a ‘ask permission’ URL on my wordpress blog, identifying itself with a particular key and perhaps a URL, and a description of what it is. In mosts cases, these requests would come in because of something I’d initiated at another service directly.

Once approved, my wordpress blog would allow xmlrpc or SOAP requests with certain payloads to act on the agreed upon pieces of data in my blog. Activities would be logged, and I could revoke or cancel access at any time via my wordpress control panel.

Well, as I was putting together some podcast show notes today, I found that Yahoo! just announced something they call ‘BBAuth’ - browser based authentication - which will allow third party apps to register with Yahoo to gain ’seamless’ access to Yahoo user’s data, with the permission of the Yahoo user. It’s pretty close to what I was thinking, except that the third party apps have to register first with Yahoo, describing what areas of a Yahoo user’s data they’d want, probably sign/agree to some terms of use, then get a registration key. The BBAuth part comes in to play when a user on a third party service site wants to grant the app access to the Yahoo user’s data. They’d log in to the Yahoo site from the third party site, agree to a data sharing terms of service agreement (probably very CYA in Yahoo’s favor!) then the originating web app is allowed programmatic access to data for that user. More info is at http://developer.yahoo.com.
It’s a nice first idea, but is still something I’d like to see become a common development pattern for more apps. CMS apps would benefit greatly from this sort of thing, I think, as would blogging tools and ecommerce apps. Explicitly granting limited access to discrete third parties (through discrete user/pass) for discrete pieces of data, controlled through a user-oriented web interface, will likely be the direction of the next generation of web services, and I say it’s long overdue already!