Announcing request-based auth, dynamic auth, and dynamic routing in OCI API Gateway

We’re pleased to announce three exciting new capabilities of the API Gateway that allow API development teams to perform more fine-grained authorizations within API Gateway and support multitenant architectures: Dynamic authorization, dynamic routing, and request-based authorization.

Overview of API authorization

Before we dive in, let’s review a basic pattern used with an API Gateway to enforce proper authentication and authorization of a client with the following steps:

1. The client authenticates with an identity provider, such as Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM), Microsoft Active Directory, and Okta. If successfully authenticated, the client receives a token that provides authorization.

2. The client invokes the API with the token.

3. API Gateway validates the token to ensure that the client is authorized to make the request.

4. If the client is authorized, the gateway routes to the appropriate backend service to fulfill the response and returns it to the client.

In step three, the API Gateway validates the received token with the identity provider (IDP), using the public signing certificates from the IDP or by invoking the introspection endpoint of the IDP to validate the token. This step represents a trust relationship between the gateway and the IDP. For the OCI API Gateway, this trust relationship is configured in the API deployment, meaning each API deployment can have a different IDP.

For most cases, this step works well. All clients are provisioned by the API provider in one IDP per API deployment. In some cases, the API needs to be multitenant, where each tenant can have a separate IDP.

Dynamic auth

With dynamic auth, the gateway can choose the appropriate IDP at runtime, based on the client request. An API can then support multitenants where tenants maintain their clients and the API provider configures the trust relationship to support each IDP. The process uses the following steps:

1. The client authenticates with and receives a token from its chosen identity provider.

2. If the client successfully obtains a token, it invokes the API using that token.

3. The gateway receives the request with the token and performs a lookup, based on an element of the request to determine at runtime which IDP to use. Options include a request header, such as x-tenant-id, the host, or subdomain that client used to invoke the API, path parameter, or even a claim in the authorization token.

4. If authorization is successfully validated, the gateway routes the request to the backend and returns the response to the client.

Dynamic auth also allows the API provider to choose how the token is validated for each tenant. Some tenants can use a JSON web token (JWT) validation and others can use an authorization function.

The example describes multitenant APIs, but it also applies to other use cases, such as trial or developer users that are stored in one IDP and then moved to another IDP when they upgrade to a paid account. With dynamic authentication, the API Gateway can decide with each call which IDP to use to validate the authorization at runtime.

Dynamic routing

Part of the responsibility of an API Gateway is to route API client requests to the appropriate backend service. API Gateway already had a robust routing capability where each path in an API can route to different backends. But what if the same path route needs to be routed to different backends based on the client? Like the configuration in dynamic auth, an API route can now have multiple backends, enabling APIs to dynamically choose the appropriate backend at runtime based on the client request.

A backend in defined in the API Gateway can be an HTTP/s uniform resource identifier (URI), an Oracle function, or a stock response. For each route, the gateway can support all three backend types. For one client, the backend can be a HTTP/s URI, where for another client invoking the same API and route, the backend is a stock response.

In the following diagram, steps 1–3 are the same. In step 4, the gateway chooses the route based on the client request, such as “/pets,” but it further examines the request to determine which backend receives the request.

Like dynamic authentication, a selector is configured to tell the gateway which part of the request is used to perform a lookup to route to the appropriate backend. The selector can be defined based on a header, query parameter, host, subdomain, path parameter, authorization claim, or the usage plan. Using this feature, API developers can define header-based routing, usage plan-based routing, tenant-based routing, and much more.

Request-based auth

The API Gateway supports JWT validation for any OAuth 2.0 compliant bearer token and provides the API developer with the power of OCI Functions service to handle any other authorization requirements on a token. With request-based authorization, this capability is extended to allow the use of multiple elements of the request. Other elements, like the path, headers, query parameters, host, body and even the client certificate if using mTLS, can be included for the authorizer function. This capability enables you to perform more fine-grained authorization decisions in an authorization function with more than one token.

Conclusion

These new features allow API developers to build APIs that can better serve multitenant clients and support authorization across multiple identity providers with dynamic authentication. API developers can segment client traffic across backends with dynamic routing. You can perform advanced and fine-grained authorization and access management using request-based authorization.

To learn more about API Management with Oracle Cloud Infrastructure, visit API Management. Dig deeper into these features and more by reviewing the documentation.