!!! Overview[1]
An [{$pagename}] is a [Proxy Server] built on the [facade pattern] that is the single entry point into the system. 

[{$pagename}] is an [Access Proxy] and typically an [Identity Aware Proxy]

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

An [{$pagename}] might have other responsibilities such as [authentication], [monitoring], load balancing, caching, request shaping and management, and static response handling.

!! [Microservices]
For [Microservices] publication, a [Microservices] [{$pagename}] 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].

!! [{$pagename}] [Architecture]
The following diagram shows how an [{$pagename}] typically fits into the [Architecture]:


[{Image src='API-Gateway/api-gate-way-arch.png' caption='API Gateway Architecture' align=left style='font-size: 120%}]\\


!! [API Service Delivery] [2]
[{$pagename}] 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 [{$pagename}] 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 [{$pagename}]’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 [{$pagename}] clearly needs to be in collaboration with the [API Registry], ingesting information about the [APIs] and how they should be exposed. The [{$pagename}] 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 [{$pagename}] should be available for ingestion by any other system that requires it, for purposes such as [monitoring], [monetization], [Metric Analysis].


Generally, [{$pagename}] 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 [{$pagename}] utilize a form of [OAuth 2.0] for determining [Access Control]

\\ [API Gateway.png]. 
\\
!! [{$pagename}], [OAuth 2.0], [OpenID Connect], [Microservices][3]
[KuppingerCole] implies that Real-life deployment patterns can be complex:
* [{$pagename}] patterns depend on integrations with [Container] orchestration platforms like [Kubernetes], cloud [PaaS] platforms like [Cloud Foundry], [serverless] computing platforms like [AWS Lambda], etc.
* API gateways offer extensive support for identity federation, SSO, token transformation (SAML to JWT, etc.) and provide integrations with popular IAM platforms
* Choosing the right [{$pagename}] solution may be the most important decision for your [microservices]-based project
* You must think beyond [security] and [Access Control]. [Monitoring], [Metrics] and [Governance] are equally crucial.

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

[API-Gateway/OAuth_diagrams-04-768x1065.png]


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 [{$pagename}] 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 [{$pagename}]. 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|Microservice] with the [Phantom Token Flow]
[Token Service Provider] enables consistent security across [Microservices|Microservice]. 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 [{$pagename}] 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:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Using an API Gateway|https://www.nginx.com/blog/building-microservices-using-an-api-gateway//|target='_blank'] - based on information obtained 2016-02-25
* [#2] - [The Core Principles of API Management|http://nordicapis.com/core-principles-api-management/|target='_blank'] - based on information obtained 2016-12-19
* [#3] - [OAuth and OpenID Connect Come Together with Externalized Dynamic Authorization|https://www.axiomatics.com/blog/externalized-dynamic-authorization-in-a-micro-services-world/|target='_blank'] - based on information obtained 2016-12-19
* [#4] - [Scalable Microservices with the Phantom Token Flow|https://curity.io/product/token-service/|target='_blank'] - based on information obtained 2020-10-06