API Management 301: OAuth-Based Access Control

Learn how OAuth provides standard patterns upon which you can deliver API access control

In API Management Lesson 201: API Security, we examine typical areas of API vulnerability and share best practices for addressing these vulnerabilities – including the use of OAuth as an access control mechanism. In this lesson, we describe how OAuth provides standard patterns upon which API providers can deliver API access control as well as touching upon related issues such as the use of OpenID Connect.

On the traditional, browser-based Web, access control methods generally assume the presence of two parties: the client and the server. Because the HTTP protocol includes specifications for basic authentication in this scenario, the core mechanisms for effective access control are already in place.

As organizations began exposing APIs to third-party apps, these mechanisms proved inadequate, as access control now involved an extra party: the app user. For example, when a social network allows an external developer to create an app for its service, users may not trust that app enough to give it their login credentials but the app needs access in order to be useful.

OAuth is an open standard for authorization, designed to address this type of problem. It prescribes a standardized way for the end user to grant third-party applications access to their server resources without sharing any credentials, putting the user in control of delegating access to an API and allowing one service to integrate with another on behalf of that user.

Social Media Example: Letting Twitter Post Tweets to Your Facebook Wall OAuth can be used to automatically syndicate a user’s Twitter posts to that user’s Facebook wall. To facilitate this, the user is redirected between Twitter and Facebook, in order to express consent. The output of this “handshake†is an OAuth token, which is used by Twitter when calling the Facebook API – allowing Twitter to effectively write on the user’s Facebook wall.

The Evolution of OAuth While the original OAuth standard (OAuth 1) was created specifically to address third-party authorization on the Web, developers gradually started applying the OAuth 1 protocol to other kinds of patterns, including the standard client-server pattern for which access control mechanisms were already in place.

That type of use became known as two-legged OAuth, whereas the end user/client/server pattern became known as three-legged OAuth. Eventually, the OAuth specification was revisited and expanded to address a broader range of use cases and requirements in a new standard (OAuth 2), which included a range of “grant types†to address more use cases.

OAuth 2 vs. OAuth 1 Although OAuth 2 (which is not backwards-compatible with OAuth 1) is more versatile than its predecessor, it is not without challenges. The main hurdle is its increased complexity – OAuth 2 is more complicated and difficult to understand, not only because of the various grant types but also because the specification itself is less prescriptive.

Whereas OAuth 1 described specifically how to implement a solution, OAuth 2 leaves much of the decision-making up to the API designer. For instance, while it provides a method for performing delegated authentication or authorization, it requires the developer to decide what the token should look like, how the client application will discover the server itself and so forth.

OAuth 2.0’s open-ended nature has advantages and disadvantages. Leaving so many decisions to the implementer increases the possibility of security vulnerabilities and interoperability issues. But this has also made it possible to build new specifications on the OAuth framework, such as OpenID Connect (which allows authentication via a third-party service).

While OAuth 2 is more complex for API providers, it is actually much easier to implement for developers building client applications. This is because OAuth 1 depended upon cryptography, having evolved from use of custom HMAC cryptography, one of the ways that API access control was handled before the OAuth specification was developed.

OAuth 2 provides a bearer token – essentially a simple string that enables the bearer of the string to gain access – thereby avoiding issues associated with cryptography and digital signatures, which can be challenging to implement for developers who are not accustomed to working with them.

While OAuth 2’s use of bearer tokens significantly improves usability for client application developers, it also requires additional measures to be taken in order to ensure security – specifically, the implementation of a secure, private connection via Transport Layer Security (TLS) or Secure Sockets Layer (SSL).

OAuth Today Finalizing the OAuth 2 specification was a long process and the finalized spec was initially somewhat controversial. However, as developers have become increasingly comfortable with it, OAuth 2 has become a core part of the security stack for Web APIs – if you need to control API access, this is the standard you use today.

Clearly then, API designers and architects need to get familiar with OAuth 2 and related specifications like OpenID Connect. It is important, however, to note that creating an OAuth implementation is not something that should be approached in a DIY fashion. You need to adopt a trusted, concrete implementation of OAuth 2 for the following reasons:

• Writing security-related code is a skill Just as writing great code is different from providing a great user experience, securing an API requires a slightly different perspective than implementing the API does – and most organizations do not have the relevant skills in house
• Implementing security solutions is hard As with other security solutions, it is significantly challenging to implement OAuth 2 in an efficient manner without adding latency to the API implementation or using resources in an unexpected way
• Mistakes are costly With security and access control, even when an attack is unlikely to happen, the effects of a breach could be catastrophic – particularly in API scenarios, where backend systems and the data these systems contain are exposed to the outside world