Julien Couvreur has a blog post entitled Web API authentication for mashups where he talks about authentication and Web APIs. This is a topic that is near and dear to my heart since getting this right is very important for the Windows Live developer platform. Julien writes
Authorization techniques:A number of techniques for controlling access
to web APIs are generally used: user authentication cookies, API keys and
crossdomain policy files. 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:Yahoo appears to be tackling the challenge with its announced "browser-based
authentication". From the little
information I could gather so far, it seems less of an authentication than
an authorization system. Unlike cookie based approaches, which give access to
any agent presenting user credentials (principal-based security), it appears to
follow a capability-based
security model, which only grants access if the agent uses the proper
"secure handle" or "capability" to call the service. Such capabilities are
sufficient to gain access to the service and don't need any additional
authentication, they are communicable tokens of authority.
The devil is in the details when talking about authentication, authorization and Web APIs. When I first heard about the Yahoo's proposed authentication model for Web APIs at their ETech 2006 talk entitled Building a Participation Platform: Yahoo! Web Services Past, Present, and Future, I thought it sounded similar to the model used by
Passport Windows Live ID. In both approaches instead of applications prompting users for their credentials (username/password combo), the user signs in to the primary service which then returns an opaque token to the target application that identifies the user and gives the application permission to access the user's data. However, having a fine grained access that can give applications access only specific services and can revoke permission given to specific applications seems to be richer than what I've seen offered by Passport Windows Live ID. This is nice but it's to be seen how easy this will be for users to understand or for applications to manage.
From my perspective there are two primary goals an authentication model for a family of Web APIs must satisfy
It should be noted that in certain cases, the information hosted in the service may not be very valuable in which case this tennet can be waived. For example, the NewsGator API expects applications to prompt users for their credentials and then pass those along when interacting with the service. Since the user information hosted in the service is primarily a list of RSS/Atom feeds and their read/unread state, the value to attackers is extremely low and there is little need to build a sophisticated authentication model for this service.
Thus far I have not seen any Web API authentication model satisfy both goals. Based on my understanding from the ETech talk, the model proposed by Yahoo! fails to meet the second goal above because it is browser based. Before being accused of bias, I'll also point out that from reading the initial documentation for the Windows Live ID service it also fails to satisfy the second goal because Microsoft has only announced SDKs for server-to-server calls and desktop clients [both of which I assume will only target servers or PCs running varieties of Windows].
Providing a comprehensive authentication story for a suite of Web APIs is a hard problem.