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
User credentials are sacred and must be protected at all costs: A security mechanism is only as strong as its weakest link. This means that it is extremely unwise to build an authentication model that has applications built on your APIs to request username/passwords or other credentials from users directly. The last thing you want is for anyone with a copy of Javascript for Dummies to be able to legitimately ask your users for their credentials then store them insecurely. In addition, if users get comfortable with entering their credentials in all sorts of random places then it makes them more susceptible to phishing attacks. This is one of the reasons services like Meebo are worrying to me.
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.
Do not discriminate against any platform or any device: In todays world, end users interact with online services using a variety of devices and platforms. Each device and platform has different strengths and limitations but is important in its own right. Online services like email or instant messaging have witnessed the rise of multiple access models from desktop applications running on PCs to applications running on mobile devices, from JavaScript code running clientside in a browser to web service calls being made from one server to another. In many cases, the average user may go back and forth between all these access modes within the course of their normal usage of the service. For example, I check my email using Outlook Web Access, Microsoft Outlook and my Audiovox SMT 5600 during the normal course of my work day.
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.