Web API authentication for mashups

Jason Levitt has been teasing me in our discussions on cross-domain requests about Yahoo's upcoming authentication API.
The recurring problem: how to offer web APIs that can be mashed up but involve personal data?
You want to allow for a large number of third parties to integrate with your services, but don't want phishing sites to abuse them.

Let me do a quick re-cap of the problem space before analyzing the pieces of Yahoo's solution.

Communication techniques:

• cross-domain web APIs using script includes,
• accessing web APIs accross domains using a web proxy,
• using a client-based cross-domain solution (see FlashXMLHttpRequest),
• neutered XMLHttpRequest with cross-domain support (see Chris Holland's ContextAgnosticXMLHttpRequest and Douglas Crockford's JSONRequest),
• cross-document messaging across domains (see CrossDocumentMessageEvent from the WHATWG).

In all these cases, there is no good authorization story, that would allow for working with personal data stored in the service in a secured way.

Authorization techniques:

The problem is that API keys and crossdomain policy files are too restrictive because the service needs to decide which third-parties to let in.

On the other end, access control based on the user authentication cookies are very open to un-planned integration, but also create a huge phishing risk.
This is a classic example of the confused deputy problems that appear in principal-based security models.

As a result, most web APIs today don't involve any user data (search, maps, ...) or non sensitive user data.

Yahoo APIs:

Let me re-iterate that I don't think this protocol is about Identity, unlike Passport, TypeKey or CardSpace (aka. InfoCard), but rather simply authority and access. This characteristic is important: we want services to cooperate without being tighly coupled at the identity level. Drew Dean's slides frames the issue as allowing "Pseudonymous delegation of partial rights", which means the names of a user in different services don't have to match and the authority that is granted is granular.

What's great about this model is that the authority carried by a capability can be as granular as the design and scenario require, and are only be given out to third-parties under certain conditions, which again are chosen to fit the desired requirements and user experience.

For example, the authority granted could vary in range in action and scope: a handle could give access to the user's entire data, or maybe only partial access to part of the user's data.
The design of the capabilities could also comprise additional dimensions, such as a time restriction. For example, a capability could be only valid for 24 hours.
One of the myths of capability systems is that capabilities cannot be revoked. It is actually possible and in Yahoo's design, any granted authority can be revoked by the user at any time.

One common policy for giving out capabilities is to get consent from the user. The screenshots of the F-Spot integration with Flickr (found on this thread) show the Yahoo consent UI.
Although I don't like the desktop/web integration in this scenario and I have some concerns about repeatedly prompting the user for consent, I believe that this approach has a lot of potential for cross-domain service integrations on the web.
Cross-domain support in browsers will be the main remaining link missing to unleash some really cool web apps. In the meanwhile, you can use FlashXMLHttpRequest or some other cross-domain workaround.

I look forward to reading the documentation when the protocol is released and trying out the resulting user experience in practical scenarios. Let me know if you find any other information.
Jason mentioned that the protocol is open and can be simply implemented, which means that it could be supported by other services and hopefully used in a wide variety of mashups.

The main problem that Yahoo is trying to solve is that not all users can be trusted (that's the old problem that was solved with user-accounts and authentication methods) but now also the applications often can't be trusted. That's why the user is asked for permission to let the application access the data.
As you already said it is not the perfect solution because we don't want the user to be nagged every time he accesses a certain services, and on the other side, how to tell a serious mashup from a phishing web app?

The question is: how much freedom is usefull for an application and what's too much? Do we really want Software we didn't even have a possibility to take a look at, really mess with our personal data?

I may give it access to my Flickr-Account, but I certainly won't give them my Banking Account information...

Regards,
Snyke

Hi Christian,
I agree with you that bank APIs and Flickr APIs are different beast, but I think that allowing Flickr types of scenario is already a good step forward.

It's a common objection to capability systems that the user would get too many security prompts (do you want to grant app X this kind of access to this data?). The solution that some capability systems, such as CapDesk, have adopted is to bundle the granting of authority with the act of designating the data. So instead of two prompts ("pick a file" and "are you sure you want to give access?"), the user would get a single prompt ("pick a file that you want this app to get access to").
The problem is how to apply this pattern to the mashup scenario.

Btw, a good presentation on capability systems was just published: http://video.google.com/videoplay?docid=-7179100659758053865

Hi Joseph,

Thanks for your comment. I'm happy to see that this topic interests more people and web companies.

I agree that the redirect approach is not a desirable long-term solution, although the user experience may not be that bad if it doesn't happen too often.
But I'm hoping it will be a bootstrap for more web APIs with proper access control to be created. When that happens the method for aquiring a token/webkey/capability can evolve, with the core infrastructure remaining unchanged.

In terms of iframe, CrossDocumentMessageEvent (the drafted cross-document API) seems quite promising. It's implemented in Opera and I'm hoping to see it in other browsers soon. It has lots of potential too, although it will have its own usability problems as well.

Btw, Tyler's presentation at Google, on the topic of authority-based access control for the web is really worth the time. It presents the basics of capabilities on the web and some essential patterns. Watch it at http://video.google.com/videoplay?docid=8799856896828158583

Hi Joseph,

I'm sorry. I erased your comment by mistake. I've been doing some pretty aggressive spam cleaning and the signal sometimes gets lost in the sea of noise I get.

To summarize your comment: although you think that Yahoo's approach is technically sound, you were concerned about the user experience of having redirects. Also, you don't like the idea that because this solution is available, it might get adopted, even though the usability is imperfect.
You are curious about the ideas that people might have to solve this, possibly using iframes or building some support directly into the browser.

[Reposting my comment from July 23rd, which accidentally got deleted. See responses above.]

Jason-great post--you really nailed the issue! We're grappling with these same challenges at Plaxo (both as a provider of APIs to access our users' personal contact/calendar/etc data, and as a consumer of over mashups and APIs, e.g. auto-import from yahoo/hotmail/etc).

On the one hand, clearly it's bad to just give sites your username/pw any time you want to access your data (no claims, the site has full access to your account and you have to trust that it won't abuse it), but on the other hand, this browser-redirect scheme of Flickr/Yahoo (and now Google, btw), where you get redirected to a 3rd party page, get told what options the app is requesting (usually with a small bit of co-branding to identify your site) and then get redirected back, is very user-UN-friendly, and it's not clear how effective it will be at preventing abuse. It's technically well thought-out (yahoo is the only place you type a yahoo pw, sites can get access to limited rights, etc.) but (a) it's always going to be a poorly integrated UI flow (esp. compared to typing in your username/pw inside the other site's pages), (b) it's scary and jarring for normal users IMO, and (c) it's not clear that casual users will understand what they're being asked or whether it's reasonable to grant access. I think it runs the risk of being another example like the much maligned "This page contains both secure and insecure content" browser warning you get when an SSL page includes a non-SSL resource (usually a perfectly harmless image or JavaScript file). Users say "uh, ok..." and sites get stuck with a lousy user experience (or they do a lot of otherwise unnecessary work to mitigate the appearance of these warnings, essentially trying to defeat the more-harm-than-good security measures in place).

What worries me is that with Yahoo and Google now supporting this style of authentication (admittedly because it's the only viable option at the moment), people may think "ok, that's industry best-practice, let's all do it". Surely we can do better! What if I could embed a little IFrame in my page when I needed the user to log into Yahoo, and they could type their username/pw in right inside my page, but it would go to Yahoo? I'm sure we could do even better with a little browser-level support for entering 3rd-party passwords (the browser could encrypt and send them in a way that my site couldn't see them, but I could still control the UI or something). I think if we don't collectively try to envision a better scenario, we're in danger of getting stuck with this redirect-to-3rd-party-and-authorize-a-confusing-list-of-capabilities solution, And beyond the poor/confusing UI that will leave us with, it will probably also motivate lots of sites to just keep asking for 3rd party usernames/passwords so they can present a more integrated experience. Given how hard it is to stop sites from doing that, it seems like the only solution is to offer a more attractive alternative. There's certainly pain associated with faking a direct user-login (esp. with sites that require multiple requests/responses, change cookies or auth tokens with each page load, etc.) so I think developers would be eager for a more straightforward auth API, just not one that says "you can't have any control over the user experience".

I'd love to here what you (and everyone reading this) has to say about this issue. I think it's really important that we discuss it and come up with better alternatives than what we have now.

Thanks! js

This is a bit off-topic, but here is the final Google TechTalk on capability security, which I highly recommend:
http://video.google.com/videoplay?docid=-7961423532989255419

It demonstrates how a secure desktop and web browser could work.