Securing APIs … do we have to consider an API gateway?

Organisms are resistant to change. The introduction of new building blocks within an existing landscape inevitably leads to discussion on the usefulness of those newly introduced systems. Because there tends to be considerable overlap in the capabilities of different solutions, it is not always easy to see how the introduction of a new building block can benefit the organization. This short article aims to provide an insight into the role and the added value of a gateway component when introduced into the landscape of an organization exposing APIs. The discussion focuses on the gateway as a generic component before differentiating between a traditional network gateway and the API gateway. We aim to provide part of the answer to the following question or statement:

“Why do we need a gateway? We already secure our back-end servers!”

To underpin the story we define a generic network topology which we reference in the rest of this article. The network contains a number of building blocks that are expanded upon as the discussion progresses.

The network we reference in the remainder of this article is divided in two different segments. One for the clients consuming our APIs, and one for the back-end servers used to realize the different APIs.

We will look at different methods in which the boundary between those networks can be realized. The first section following this introduction, ‘The Gateway Component‘, will contrast the use of a central network component on the boundary with the more direct approach of foregoing any central platform. In the second situation, the boundary is realized on a network level only and consumers use point-to-point connections to reach their target APIs.

Once we determined the potential benefits of adopting such a central platform, we can look at the difference between the traditional gateway, and the API gateway used in most API management solutions. Do we use a network gateway to secure our APIs? Do we use an API gateway instead? Do we use both? Those are the questions we try to tackle in the section following the introduction of the gateway.

By structuring our discussion around the increasing complexity of our reference network topology, we hope to provide some insight into the following topics:

• The role of a gateway in securing APIs
• The API gateway vs the network gateway

The APIs we expose are implemented on our back-end systems. The support for securing those API implementations varies depending on the chosen framework and technology. Most modern implementation frameworks, however, provide at least some way of securing APIs. The question that often arises when discussing the introduction of a gateway component is the following:

“Why introduce a gateway when we already secure are back-end servers anyway?”

There are a number of reasons to introduce a gateway component. Many of those reasons can be summarized using the well-known adage: “Use the right tool for the job”. While back-end servers & frameworks are well-equipped to tackle the challenge of implementing your APIs, they are typically not designed for policy enforcement and security. The remainder of this section aims to exemplify this in a number of areas.

The central position of the gateway provides a number of benefits in terms of governance. As an example: Back-end servers that want to perform client authentication using certificates have to, in the absence of a gateway component, manage the different client certificates on their own. The task of managing certificates on multiple servers can quickly become complex. By placing a gateway in front of the different APIs, the certificate management can be centralized, significantly reducing the complexity.

Network configuration is simplified by providing a single entity that is reachable from outside networks. The distinction between internal and external becomes easier to manage. Without a gateway, each resource server would have to be individually configured as reachable. Having multiple access points increases both the complexity of the network configuration and the attack surface exposed malicious actors.

By centralizing the security on a gateway, we can reduce the infrastructure needed to run the different API implementations. This infrastructure is further protected by the ability to manage traffic on a per client (or service) basis, and by stopping unauthorized calls before they reach the back-end, implementing the so-called ‘Fail Fast’ principle.

The offloading of security related tasks to the gateway makes for a better separation of concerns. Allowing the security to be managed independently from the resource servers or the API implementation.

Because the gateway is positioned centrally, any detected security incidents can easily be logged, providing global security monitoring for all services running within the organization.

The available security features or protocols are often more limited in a back-end servers than the ones available on a dedicated gateway. For example: OAuth, OpenID Connect, and support for integrations with external identity providers is often present in gateways without additional implementation.

This limited support could prove challenging, as different clients would have to support different security mechanisms for each API, depending on the support of the underlying implementation. The gateway can act as a layer of abstraction. By positioning a gateway between the back-end servers and the clients (consumers), the gateway can provide a set of standard security mechanisms. This standard security information can then be translated as needed for the underlying back-end servers. This concept is visualized in the figure below.

Specialized security features are rarely available in API implementation frameworks. By using a gateway supporting integration capabilities with virus scanning software we can provide in-flight virus scanning ability for all our APIs. In the same vain mitigation for common attack methods like SQL injections can be provided for every new API without impacting their implementation.

While the section above on the advantages of a gateway component might be enough to convince us that the introduction of a gateway component can be beneficial, it does not answer the following question:

“What differentiates the API gateway from the classic network gateway?”

In this section, we hope to provide parts of the answer to the question above.

The source of the differences between gateways and the API implementation frameworks also lies at the core of the differences between the API gateway and the traditional network gateway. They are built with a distinct focus in mind. While the classic network gateway aims to implement global security requirements, the API gateway enjoys the benefits of a more narrow scope. The API gateway can enforce API specific policies.

Many of the elements discussed is the context of a generic gateway component are present in the API gateways. As an example: The ability to shape traffic and throttle specific consumers or services is provided by most API gateway implementations. But in contrast to a network gateway, the API gateway can shape traffic on the level of individual API operations and resources.

Because API gateways are built to manage APIs, they tend to come equipped with the ability to parse and interpret API definitions. Tasks that are difficult to perform for the traditional network gateway, like input validation or filtering, are often easier on an API gateway because of the increased contextual awareness available through the interpretation of the exposed API definitions.

A first coarse-grained pass for authorization can be performed by the API gateway, leaving only the fine-grained authorization to the server hosting the APIs. This can include the translation of reference tokens to self-contained id tokens.