An API-Gateway is a Proxy Server built on the facade pattern that is the single entry point into the system.

API-Gateway is an Access Proxy and typically an Identity Aware Proxy

API-Gateway is similar to the Facade pattern from object-oriented design. The API-Gateway encapsulates the internal system architecture and provides an API that is tailored to each client type.

An API-Gateway might have other responsibilities such as authentication, monitoring, load balancing, caching, request shaping and management, and static response handling.


For Microservices publication, a Microservices API-Gateway provides a static address for end-User, and dynamically route requests to the appropriate service address. In addition, providing authentication and often TLS termination for security are typical considerations in exposing a service to other End-Users.

API-Gateway Architecture#

The following diagram shows how an API-Gateway typically fits into the Architecture:

API Gateway Architecture

API Service Delivery [2]#

API-Gateway is where the API Service Delivery happens as it is the component responsible for exposing the organization’s APIs to the Consumer of services (which can of course be internal or external).

In brief, the API-Gateway covers the following key areas (for a detailed discussion of the capabilities of the API Gateway please refer to our previous blog post on the subject.):

  • Manifestation - Exposes the organization’s APIs to the outside world, acting like a proxy to route requests from external consumers to the API itself (as an aside, many API management solutions can also support backendless APIs, implementing the entirety of the API on the Gateway itself
  • Security - is the a Policy Enforcement Point for the API, applying Access Control Models on behalf of the API. Applying Access Control at this outer perimeter is consistent with the cyber security principle of “defensive in depth” and is an important feature of the API-Gateway’s capabilities
  • Entitlement - Allows access to APIs at the agreed upon rates and either limiting or managing traffic;
  • Standardization - Presents a uniform suite of APIs to consumers (according to any API standards an organization might have);
  • Logging and Metrics capture - Captures the information required to understand API utilization.

In order to expose, secure, and manage an organization’s APIs the API-Gateway clearly needs to be in collaboration with the API Registry, ingesting information about the APIs and how they should be exposed. The API-Gateway should also establish a feedback loop, supplying the API Registry with management-level metrics on API utilization, in order to help maintain an accurate picture of how the organizations APIs are used and thus their relative importance for future capacity and investment decisions.

Finally, metrics captured by the API-Gateway should be available for ingestion by any other system that requires it, for purposes such as monitoring, monetization, Metric Analysis.

Generally, API-Gateway is a Policy Enforcement Point which uses Policy Based Management System typically using a Identity Provider (IDP) for Authentication and a the Policy Decision Point to determine Authorization to a resource.

Most modern API-Gateway utilize a form of OAuth 2.0 for determining Access Control

API Gateway.png.

API-Gateway, OAuth 2.0, OpenID Connect, Microservices[3]#

KuppingerCole implies that Real-life deployment patterns can be complex:

This diagram shows an example of an architecture for guarding Personally Identifiable Information (PII):


Let’s assume that the OAuth Client already has an Authorization Code and is acting on behalf of Alice. The OAuth Client is issued an access_token using its Authorization Code, client_id & Client Secret, typically. The client then makes a business API call with the access_token. The Resource Server, typically an API-Gateway acting as an intermediary for the Business Service, validates the access_token against the Authorization Server. The OAuth 2.0 Authorization Server may return attributes about Alice to the API-Gateway. Once verified, the Gateway brokers the business API call.

OAuth 2.0 uses the term Authorization Server to describe the role of an actor in the various OAuth 2.0 Protocol Flows that authenticates the Digital Identity of the Resource Owner, and issues and validates tokens for the API Clients. While the Authorization Server can perform some authorization tasks, let’s assume for this article that the Authorization Server just issues tokens and provides context. We will go into the various scenarios where the Authorization Server may play a bigger role in the next portion of this series. XACML terms will be used to describe the various components of the “Externalized Dynamic Authorization service”.

OpenID Connect like OAuth 2.0, does not however, define how authorization decisions are to be made. The context provided by the id_token and Userinfo_endpoint can be used by the Policy Enforcement Point to formulate a request to a Externalized Dynamic Authorization Management systems.

The Resource Server can act as the Policy Decision Point for binary authorization decisions. The OAuth Authorization Server can pull OAuth Scope from the Policy Decision Point and include within access_token, once approved by the Resource Owner. OAuth 2.0 provides authentication and contextual attributes that can leveraged in policy decisions in both cases. While OAuth 2.0 and OpenID Connect also provide authorization capabilities, there may still be a case for supplementing with a more Externalized Dynamic Authorization Management service.

Scalable Microservices with the Phantom Token Flow#

Token Service Provider enables consistent security across Microservices. Each microservice expects an Access Token in JSON Web Token (JWT) Format. On the Internet Opaque tokens are used and traded for JWTs in the API-Gateway or the Ingress Service for internal use. Keeping the information safe, whilst ensuring access internally.

More Information#

There might be more information for this subject on one of the following: