A key technical underpinning of the Cloud is the Application Programming Interface (API). APIs provide consistent methods for outside entities such as web services clients and desktop applications to interface with services in the Cloud. More and more, it will be through APIs that cloud data moves; however, the security and scalability of APIs are currently threatened by a problem called the password anti-pattern – the need for one API to collect and replay the password for a user at another API in order to access information on behalf of that user. OAuth defeats the password anti-pattern, creating a consistent, flexible identity and policy architecture for web applications, web services, devices, and desktop clients attempting to communicate with Cloud APIs.
Like many applications today, TripIt (http://tripit.com) is a cloud-based service. TripIt is a travel planning application that allows its users to track things like flights, car rentals, and hotel stays. Users email their travel itineraries to TripIt, which then builds for the users a coordinated view of their upcoming trips (as well as those of their TripIt friends – the inevitable social aspect). TripIt is undeniably useful as an isolated service; having a single cohesive view of travel plans (accessible from both web and phone) is a boon to business travelers. But TripIt becomes significantly more useful and valuable when, rather than being isolated, its view of travel plans becomes integrated with the user’s existing identities.
For instance: a. Insertion of TripIt travel itineraries into online calendars such as Google Calendar b. Detection of new travel itineraries directly from the user’s email inbox c. Automated publishing of travel details to social networks d. Integration of travel dates and trip segments into corporate expense reporting applications All of the above integrations can be accomplished through the use of APIs. In some cases TripIt must act as a web services client to leverage APIs offered up by other services. In other cases TripIt would need to make the traveler’s itinerary available to other services via its own API. Given that the identity data and attributes stored behind either of these APIs are potentially sensitive, the traveler will surely want some level of control over access.