June 19th, 2009 by John Reeve

Building an API?

In the midst of building an API for Intervals, our web-based project management software, we researched several options for authentication. In case you are considering building your own API, we’ve published an overview of each method below.

1. HTTP Basic Authentication.
   Similar implementations: Basecamp (http://developer.37signals.com/basecamp/), blogger (deprecated) (http://code.blogger.com/archives/atom-docs.html#authentication)
   Requests are authenticated in the form of the user’s username and password. Very easy to implement. Low security, but can be reinforced through the use of SSL/TLS (available on top three plan tiers). Users can disable API access from third-party apps at any time by changing their username or password.
2. HTTP Token Authentication
   Similar implementations: Freshbooks (http://developers.freshbooks.com/), Highrise (http://developer.37signals.com/highrise/)
   Requests are authenticated through a token. Each user possesses a unique token, retrievable on that user’s settings page. Rather than entering username/password information, users just key in their token. Also very easy to implement. Low security, but requires a more active role from the user. Security can also be reinforced through SSL/TLS (available on top three plan tiers). The token is a hash of the username and password, meaning users can enable or disable API access from third-party apps at any time by changing either. With this implementation and the ones following, users never have to hand over login credentials to third-party applications.
3. Three-Legged Authentication
   Similar implementations: Facebook Connect (http://wiki.developers.facebook.com/index.php/Authenticating_Users_with_Facebook_Connect), Yahoo! BBAuth (http://developer.yahoo.com/auth/), Google AuthSub (http://code.google.com/apis/gdata/auth.html#AuthSub)
   In this approach, each developer registers for an API key. Requests are authenticated through the developer’s API key and a user token. A token is retrieved when the API application redirects the user to a secure Intervals login page. After the user grants access to the API application, the API application retrieves the token. High security, but harder to implement. Also, a browser is required to grant authorization (though just once). May be overkill for developers building in-house applications. Users can disable API access per application by revoking access.
4. Three-Legged Authentication with Request Signing
   Similar implementations: flickr (http://www.flickr.com/services/api/auth.spec.html), OAuth (http://oauth.net/core/1.0/#anchor9), Twitter (uses OAuth: http://apiwiki.twitter.com/OAuth-FAQ), Google OAuth (uses OAuth: http://code.google.com/apis/gdata/auth.html#OAuth), Yahoo! BBAuth
   Identical to #3, except API developers select a secret password when they register for an API key, and use this password to sign all requests. If any requests are intercepted, no modified requests can be made unless signed by the password known only to the developer and Intervals. Very high security (though not impenetrable), but more difficult to implement. May be overkill for developers building in-house apps. Options 3 and 4 can be implemented simultaneously with the decision to sign requests left up to each API application developer.

Related posts

• What’s next for Intervals? – Intervals Roadmap Update (1)
• Stringing along programs and APIs? (0)