What do we want? API Access!

When do we want it? Now!

I’s time to change your entire mindset. We’re talking about API security, but not for traditional APIs. API gateways are a response to the “open API” movement, and create a very different development environment.

As we mentioned in our introduction, API gateways are an enabling technology, but likely not the way you think they are. Companies want to expose their services to a wide audience, but rather than design and build consumer offerings in-house they often provide API access to their services to contractors – and in many cases to the general programming community. For companies like Twitter, Facebook, and YouTube (Google), the trend is to allow third-party developers to extend and integrate these platforms to provide novel new user experiences. It’s a win/win: the company gets to leverage innovations from the third-party community, users get better apps, and developers get paid (the average force.com developer makes $392k/year for their work. It can be an almost free way to leverage the best ideas in the development world – you just have to accept the risk of random people groping around your services and data.

Leveraging the community for innovation and pro bono development raises some new security problems – how can you control your API while actively making it available outside your company? Not that many years ago, companies wrestled with serving up data to consumers outside the firewall – letting them write code to run on top of proprietary systems is downright scary. To provision developer access, and to control what they can use and how, you need some form of API management framework.

API gateways are this framework. From the developer’s perspective they function like a traditional development environment: they bundle a number of features under one umbrella to provide basic tools developers need and make API integration as simple as possible. For the API provider, rich and accessible services encourage developers. The flipside is trying to manage developers who don’t work for your company, and giving up control over endpoints and user experience. Additionally, you need to control access and features through tokens and keys. 80% of your API gateway effort will focus on what developers need to leverage your service, but the most difficult 20% will be managing developers’ experience and exposing services, which requires attention on ease of use and hiding complexity from developers.

API gateways are for extending features to developers, so most of our examples are from the development perspective. Our outline follows the path developers will take to use your APIs. We will start from ground zero, as developers register themselves to use your service, considering how you will provision developer access. Per the outline in our introduction we will then move into other areas of development tools, key management, and other critical areas of API security.

On our journey we will straddle two realms: buyers and builders. For builders, we will show you examples of features you need to build into your platform. For those of you looking to acquire an API gateway, consider this a mirror image of your critical platform criteria and where you will need services to get your deployment over the finish line.

Provisioning

As simple as it may seem, provisioning for API gateways is a balancing act. On the one hand companies want simple streamlined access for developers to build functionality. On the other hand they want to ensure this all complies with security policies. How can you ensure security while providing developers with full access? What process will ensure the right mix of policy checkpoints without hampering developers? Therein lies the rub.

Let’s look at a developer’s first step: getting access to the development environment.

Developer access provisioning

Perhaps you have heard that developers can be a tad mercurial? Development is about building and enabling, so security controls which restrict usage or limit functions are seen as an impediment and source of friction. Keeping developers on board with security policy is a challenge, especially when any number of them don’t even work for your company. Development tools are typically selected for ease of use, so streamlining access to tools and simplifying access to API functionality is critical.

API gateways proxy communications to applications – they act as traffic cops to direct application requests according to policy. That middle ground is a vital place for security to focus for three reasons:

1. It is a boundary between internal and external, making it an ideal place for policy enforcement.
2. It is a logical place to monitor inbound and outbound access.
3. It is where developers get everything they need to create applications.

What do developers need to get started coding? They need to be vetted to the API, which means they need to get credentials. These credentials come as tokens and possibly certificates. API gateways should provide what developers need to find and bind to your API to begin coding. First, developers generally need to register with the gateway to initiate the key issuance process and get credentials to your API. This may require a few minutes for a simple automated process, or much longer for requests which require manual review. Once accepted, developers receive credentials – often only to a development and testing instance, with production access to follow.

How this process works, and how simple it is to implement, are important factors for selecting an API gateway. How well can your candidates be tuned to your organizational needs? When building an API gateway, be realistic about what developers will tolerate in terms of delay and complexity. Grand processes with many steps tend to stop developers in their tracks.

The API documentation is another major factor in simplifying developers’ lives. The favorite words of many developers are “for example”, typically followed by a code snippet and a usage explanation. The goal is to get developers up and running quickly so look for code samples, reference implementation, and test clients when you evaluate API gateways. A wide variety of languages are in play, so over time you will likely your own miniature United Nations – supporting REST, JavaScript, iOS, Android, Java, Python, .NET, and other implementations so developers can learn from frameworks they are comfortable with. Time they spend learning the intricacies of your platform is not spent building great tools for your prospective users.

But what about security?

Access tokens are the coin of the realm – they enable just about everything. Developers need to get access tokens, build them into apps, and use them at runtime. As much as security folks wish all developers were fascinated by the deep internals of identity and cryptography, most just don’t care. API gateways mean developers do not need to be expert with identity token systems, or with how to route users to the correct services. The gateway’s role is to simplify these security steps, and provide users the right view according to their credentials.

Credentials such as OAuth access tokens are critical for API access control. The gateway’s job is to provision these tokens to developers so they can build them into applications as needed. Tokens are used by applications at runtime to provide identity for access control, and to facilitate monitoring so no developer can hammer your service too hard.

Just as API gateways show developers how to code clients, they also provide tools to help developers navigate the often byzantine world of identity and access protocols. Netflix’s authentication walkthrough is a good example. Short and to-the-point, their walkthrough leads developers through acquiring and using an access token.

The API gateway should mask many of the complexities of token issuance and management, but developers cannot afford to be wholly ignorant to how tokens provide security. They need at least a basic understanding of identity and access tokens, how they work, and what they do not do. Attackers find and abuse the gaps between what is expected and what is provided. Take the most common access token: OAuth – called both an authentication token an authorization token. But in practice it isn’t quite either. OAuth provides access tokens which can be used by application to make access control decisions, such as authorization. Developers should know how to get things working with identity and access tokens, as well their additional responsibilities for implementing a full access control chain. The token is an essential part but there are many other application and protocol areas to address for safety.

Administration and Policy Provisioning

API gateways are developer enablement tools, but they are not only for developers. Administrators use gateways, with their central position, to deploy and enforce policies governing API runtimes. Typical policies include monitoring, metrics, throttling, and caching.

The API gateway is a registry of the application’s interfaces, so the security team can leverage it to create and enforce policies for malicious input such as SQL injection, XSS, CSRF, and other web-app style attacks.

For application monitoring, the API gateway can act as a sensor collecting inbound and outbound messages. These messages may be tagged with additional context and sent to a SIEM and/or written to an audit log.

Of course there is no silver bullet. Developers are moving quickly – we will see just how fast in our next post. To remain relevant security teams need to be quick too. We need as many tools and as much automation as we can get. Building around central choke points is immensely useful for gaining visibility and ensuring identity protocols safely control access.