Protecting Application Programming Interfaces

Application Programming Interfaces (APIs) have been around for decades. APIs allow one computer program to talk directly to another, possibly running on some other machine. These communication channels allow programs to properly request and receive data using various protocols, such as Representational State Transfer (REST).

The use of APIs frees you from creating functionality you would rather not develop, optimize, or maintain. Google provides APIs to dozens of capabilities, such as 2D and 3D maps, photo editing, search, calendars, news, translators, and YouTube videos. Companies such as Facebook, Amazon, Twitter, Salesforce, WordPress, Flickr, Dropbox also provide access through APIs to capabilities that can be used as building blocks for your application.

REST, typically used with HTTP, has become the most popular way for applications to communicate over the Internet. REST APIs should be secured using a lightweight and scalable approach, such as OAuth 2. The OAuth standard supports different profiles that allow it to be used in different ways. Applications can use OAuth to allow users to access their protected accounts on, for example, Google, Facebook, Microsoft, or Twitter without exposing the user's password.

An OAuth profile is displayed in the first figure. Notice the password is exchanged only between the user agent (e.g., the resource owner's browser) and the authorization server. Also notice the token is only provided to the client. Some describe these features as "privacy by design."

OAuth allows authorizations to be divided into scopes, instead of using an all-or-nothing design. Scopes permit the authorization server to grant access to specific resources as directed by the resource owner. That is, one requester might be allowed access to a resource owner's contact information, while another requester would be refused access. Note, in this model the resource owner must be present to participate in the authorization.

The second figure displays a adaptation of the OAuth model called user managed access (UMA). UMA gives the resource owner (user) the ability to control who has access to resources without requiring that the user must be present. Instead, authorization is determined by an authorization server which enforces the user's access policy. UMA also allows users to select one or more resource servers that will release those resources upon proper authorization. Since UMA uses OAuth to secure each API, there are three OAuth tokens. The second figure shows how the APIs and corresponding OAuth tokens (PAT, RPT, and ATT) are related.

As technology changes, there is opportunity to use it in a novel way to solve problems and produce products.