API-Gateway Architecture#The following diagram shows how an API-Gateway typically fits into the Architecture:
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.
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.
API-Gateway, OAuth 2.0, OpenID Connect, Microservices#KuppingerCole implies that Real-life deployment patterns can be complex:
- API-Gateway 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 API-Gateway 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.
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.