June 28, 2006
@ 03:27 PM

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

  1. 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.

  2. 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.


Categories: XML Web Services
Tracked by:
"Interesting Finds: June 29, 2006 AM edition" (Jason Haley) [Trackback]
"Yahoo Launches Browser Based Authentication (BBAuth)" (Dare Obasanjo aka Carnag... [Trackback]
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=d72faa5c-c997-4b9e-b5a7-66... [Pingback]
http://www.google.com/search?q=ilgojpqu [Pingback]
http://toxgxlv.net/movies/sitemap1.html [Pingback]
http://zabivwn.net/arkansas/sitemap1.html [Pingback]
http://weujmru.net/pets/sitemap1.html [Pingback]
http://pcbaqlu.net/02/sitemap1.html [Pingback]
http://otjjblj.net/03/index.html [Pingback]
http://yftbsy1.net/lottery/sitemap1.html [Pingback]
http://restablog.dreamhosters.com/beauty/sitemap1.html [Pingback]
http://ptmy0sx.net/colorado/sitemap1.html [Pingback]
http://kivablog.com/sitemap1.html [Pingback]
http://oymykjb.net/sitemap1.html [Pingback]
http://www.freewebtown.com/randevy [Pingback]
http://bombaylogger.web.aplus.net/01/index.html [Pingback]
http://lf0s3on.net/artists/sitemap1.html [Pingback]
http://tulanka.readyhosting.com/estate/sitemap1.php [Pingback]
http://kiva.startlogic.com/sitemap1.html [Pingback]
http://restablog.dreamhosters.com/motorcycles/sitemap1.html [Pingback]
http://host239.hostmonster.com/~blogford/sitemap2.html [Pingback]
http://host239.hostmonster.com/~blogford/sitemap1.html [Pingback]
http://gator413.hostgator.com/~digital/career/sitemap1.html [Pingback]
http://gator413.hostgator.com/~digital/college/sitemap1.html [Pingback]
http://gthgkir.net/sitemap1.html [Pingback]
http://fwve5e4.net/youporn/sitemap1.php [Pingback]
http://ask-a-blog.com/sitemap1.html [Pingback]
http://mwtobvc.net/15/index.html [Pingback]
http://eaerowb.net/sitemap1.html [Pingback]
http://zvbvids.net/sitemap1.html [Pingback]
http://box432.bluehost.com/~zbloginf/sitemap1.html [Pingback]
http://d579737.u108.floridaserver.com/sitemap2.html [Pingback]
http://gator442.hostgator.com/~hockteam/games/sitemap1.html [Pingback]
http://gator442.hostgator.com/~hockteam/southwest/sitemap1.html [Pingback]

Wednesday, June 28, 2006 4:31:52 PM (GMT Daylight Time, UTC+01:00)
I get a different impression from reading the same Windows Live ID document. It appears that you guys plan to provide class libraries that make it simpler to use Windows Live ID from Asp.Net (I assume that is going to be the server SDK) and Windows client apps. But these class libraries seem to be just wrappers around some web services. Figure 1 for example shows that some third parties will connect via those SDKs, while others will connect via the "raw" web services. They also mention that they will accept other authentication methods, like Radios, to support even more devices. I also believe that Kim Cameron is quite involved with this, and anyone reading his blog will know that he would not fall into the trap to do something that doesn't solve your 2 problem. He is quite on top of things ;)
Wednesday, June 28, 2006 4:32:37 PM (GMT Daylight Time, UTC+01:00)
I meant "Radius" of course :)
Wednesday, June 28, 2006 6:16:48 PM (GMT Daylight Time, UTC+01:00)
Just having web services doesn't mean you have an authentication story that has wide reach. The SOAP vs. REST perma-debate makes that abundantly clear.

Can my javascript Web gadget running in a browser mashup talk sophisticated authentication protocols based on WS-* web services? Can my mobile phone? How about my Apple Powerbook?

Wednesday, June 28, 2006 7:34:37 PM (GMT Daylight Time, UTC+01:00)
I did not say that Windows Live ID will have wide reach. You claimed that Windows Live ID fails in the reach point because it will only have SDKs for for desktops and servers and therefore would be limited to clients running on Windows. But that reason surely is wrong, because one does not need those SDKs (or class libraries) in order to access the service.

Whether the services will expose their functionality in a way easy enough to get the reach you imagine is a different question. I don't see how one can answer that from the information available today, since none of the details have been published.
Wednesday, June 28, 2006 9:45:25 PM (GMT Daylight Time, UTC+01:00)
Again based on the limited information I have found so far I looks like Yahoo's "browser-based authentication" (bbauth) handles both concerns correctly.
Only Yahoo gets to see the user's credentials for Yahoo services.
From what Jason Levitt told me, their design goal was to keep the protocol open and simple, not depending on a specific platform. It looks like both desktop clients and web apps could access services using bbauth. In terms of javascript dependencies, the screenshots of F-Spot integrating with Flickr don't suggest a lot of fancy AJAX stuff.
Wednesday, June 28, 2006 11:20:22 PM (GMT Daylight Time, UTC+01:00)

Smells like passport, but only just started to read up on it...
Thursday, June 29, 2006 11:31:21 PM (GMT Daylight Time, UTC+01:00)
> 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].

I am fairly sure this isn't true.. I remember that question being asked of the InfoCard team @ MIX06 and they referenced a linux implmentation that was already underway.
Friday, June 30, 2006 12:04:15 AM (GMT Daylight Time, UTC+01:00)
Windows Live ID != InfoCard
Comments are closed.