API Gateway

F5® Distributed Cloud Mesh’s API Gateway service is a distributed service that enables users to build, deploy, publish secure, and operate APIs. An API gateway handles all the services required for delivering APIs such as Authentication, Authorization, API routing to origin services, and applying rate limiting and security policies. Mesh’s API Gateway service is a globally distributed service that can be deployed across the user’s public, private, and edge clouds as well as on F5 Distributed Cloud’s Global Network. Mesh’s API gateway service is centrally managed from F5® Distributed Cloud Console .

Figure: Mesh API Deployment

Mesh API gateway includes the following key features that map to the typical lifecycle of an API.

Figure: Figure: Mesh API Gateway Features

The next section describes each of the features in greater detail.

  1. Authentication
  2. Role-Based Access
  3. Authorization
  4. Rate Limiting & Security Policy
  5. Monitoring, Metering, and Accounting
  6. API and Developer Portal

Mesh API Gateway Features

1. Authentication

Authentication validates the identity of the client/caller, i.e., is the client/caller really who they claim to be

The clients to be authenticated can be categorized as

  • Human-backed clients: This includes humans behind the browsers, mobile apps, javascript running in the browser.
  • Application/software clients with no humans behind the client

Mesh API gateway supports multiple methods of authentication depending upon the client.

  • Human-backed clients - Mesh API gateway uses OpenID Connect (OIDC) based authentication to authenticate such clients.
  • Application/software clients with no humans behind the client: Mesh API gateway uses one of the following methods to authenticate such clients
    • mTLS based authentication
    • API key-based authentication

Human-backed Clients : OpenID Connect (OIDC) based authentication

OIDC is an identity layer on top of the OAuth2.0 protocol. It enables verification of the identity of the client and enables retrieval of basic profile information of the client in an interoperable and rest-like manner. Please visit OpenID Connect to learn more about OpenID Connect.

The OIDC authentication server used to authenticate the clients differs based on whether the API being served is a public API or a private API.

  • Public API: F5 Distributed Cloud supports authentication against public OIDC authentication services such as Azure-AD, Google, and Okta. Clients will be redirected to these public OIDC services to get authenticated before continuing their journey on F5 Distributed Cloud.

  • Private API: In the case of private APIs, the authentication mechanism is still based on OIDC, where the user is responsible for configuring an OIDC gateway to their native authentication system. F5 Distributed Cloud could provide custom integration with popular OIDC gateways subject to the negotiation of business terms.

Application/software clients with no humans behind the client

Mesh API gateway uses one of the following methods to authenticate depending upon the type of client traffic

  • mTLS
  • One-way TLS + Layer 7 (e.g., HTTP) based authentication
    • API key/Service Token

In the case of mTLS, authentication is performed using the certificate presented by the client during TLS handshake and validating the certificate with the identity (i.e. the certificate) provider. If the identity (i.e., certificate) provider is trusted and the certificate is valid, then the communication is authenticated. Whenever a client certificate is presented by the client, it should contain the “user-id” in the certificate. At present, we only support the certificates issued by us. Support for certificates from 3rd party PKI providers needs to be evaluated on a case by case basis.

In the case of one-way TLS, there is no client certificate presented by the client like mTLS. Therefore in the case of one-way TLS, Mesh API gateway checks if the request is L7 (e.g., HTTP) based. If L7 (e.g.,, HTTP) based request, then the system performs additional Layer 7 level authentication such as

  • API Key, also known as Service Token. Users can create a service token in Console and specify the roles donned by the service. As the service token is generated via Console , the token’s validity is authenticated against the F5 Distributed Cloud identity authority. Users are provided the ability to revoke a service token as well.

2. Role-based Access

Once the client is authenticated, we need to determine what APIs the client is authorized to access. Instead of creating policies for each client individually, Role-based Access maps the clients into a set of roles (e.g., developer/admin role, basic vs/ premium user) and assigns policies to each role. Authorization then checks against those policies and allows or denies the API call.

Mapping of clients to roles can be achieved in the following methods

  1. Statically - The user could configure a static mapping of the client to a role in Console .
  2. Dynamically - Typically users may have already set up their client to role mapping in their organizational directory such as Azure AD, Google suite. The system fetches the mapping between clients and roles from the organizational directory using SSO and provides that to the API gateway.
    1. In the case of a public API where clients could be consumers, no such directory exists. However, the user might want to map clients based on some business logic, e.g., basic vs. premium client or US vs. Mexico client. For such scenarios, The system will provide a webhook enabling the user to inform the client-to-role mapping.
    2. Furthermore, it might not be possible to perform such a client-to-role mapping at configuration time and may need to be determined at run-time based on client attributes. The system addresses these scenarios by allowing users to write business logic in a webhook invoked at run-time for every client access. Note while this offers the maximum flexibility, this is an expensive operation in terms of performance and will be supported in the future.

3. Authorization

Once the client is authenticated and the role is determined, the authorization step involves checking the policy and action configured for the role. For example, if client foo tries to access API-1, the role mapped might have configured a policy indicating that foo is not allowed to access API-1 and the access will be blocked. Authorization policies can be applied to individual APIs or groups of APIs.

API Groups

APIs can be grouped based on method and path e.g.,

API group 1 Method = GET
Path = /service/productcatalog/foo
Path = /service/productcatalog/bar
API group 2 Method = POST
Path = /service/cart/paymentmethod
Path = /service/cart/address
... ...

Authorization Policy

The authorization policy specifies an action per role and API group. It can be visualized simplistically as follows

Role api-group1 api-group2 api-group3 ...
developer-role allow deny Rate limit allow
monitor-role Rate limit deny allow deny
... ... ... ... ...

The following policy actions are supported

  • Allow
  • Deny
  • Rate limit (on roadmap)

4. Rate Limiting and Security Policy

Mesh API gateway protects the user’s application against security attacks at the network and application layer as well as set granular rate limit policies as described next.

Security Policy

Mesh API gateway enables the following security features:

At the application layer:

  • Application firewall - Application layer security policy to protect against sophisticated application-layer attacks like SQL injection

  • Captcha/JS challenge - Protect against suspicious users and bots using captcha/JS challenge

  • API Usage Characterization - DevOps teams don’t always know a lot about the APIs developed by the developers, yet they need to understand how and when the APIs are used in order to create security policies and optimize performance. DevOps can characterize the APIs advertised on the API gateway at a fine-grained level using the APIs Probability Distribution Functions (PDFs).

  • User Anomaly detection - DevOps and Developers can detect anomalies per APIs per client where a client is identified by

    • Client IP address
    • Cookie name
    • Http header name
    • Query parameter key
  • At the network layer:

    • Network firewall - Network security policy to block IP addresses, AS numbers, network ports.

Rate limiting Policy

Developers and DevOps teams can protect APIs and ensure SLAs for API consumers by setting a maximum request rate, per second/minute, per API path, and method. Furthermore, the APIs can be categorized into groups and the rate limit policy applied per API group as well. DevOps can set multiple rate-limiting policies depending upon their needs. Rate Limiting can be configured at a per-client granularity where the client is identified as follows Client IP address Cookie name Http header name Query parameter key

The API gateway and the origin services providing the API could reside in different namespaces. This aligns well with customers' existing operational model as the services providing the APIs are managed by a different team compared to the team managing the API gateway itself.

5. Monitoring, Metering, and Accounting

One of the most critical functions of an API gateway is to provide API monitoring, metering, and accounting to developers and DevOps teams.


API performance monitoring is required for internal use, while metering and accounting is used by users to meter and bill APIs to their end-user.

Mesh API gateway provides eyes-on-glass monitoring of API performance, latency to origin service, requests/responses per second, requests/response size and 4xx/5xx errors per second, and health check failures. Users can get insights into API performance via real-time statistics as well as historical trends. Users can baseline normal usage and identify deviations from normal via Mesh’s time series analysis and anomaly detection.

F5 Distributed Cloud encapsulates all these metrics into an easy to consume KPI called Application Health Score that users can use to get a quick status on the health of their application.

Mesh API gateway also provides alerts for each metric mentioned earlier, categorized into multiple categories such as Critical, Major, Minor with granular alert policies to avoid alert fatigue. Alerts are integrated with monitoring tools such as Slack, OpsGenie, PagerDuty, and Servicenow aligning with existing operational workflows.

Metering and Accounting

Users can avail of all the metrics mentioned above for metering and accounting purposes for their end-users. Mesh API gateway enables operations teams to report on the API consumption metrics as well as bill their end-users by API usage.

6. API and Developer Portal

Mesh API gateway enables users to define multiple API portals, e.g., Public APIs published to an external API portal, while internal APIs published to a developer portal. The API portal(s) is decoupled and logically separated from the API Gateway Data plane. Each API portal can be deployed in different environments with unique branding for each. For example, the developer portal deployed in private cloud, while public API portal deployed in the public cloud or F5 Distributed Cloud’s Application Delivery Network.

Developers and DevOps teams could integrate API management into their DevOps workflows and CI/CD pipelines by

  • defining and publishing APIs to development → test → stage → production API portals.

Configure granular access control to each environment’s API portal for specific roles and users.

  • Run multiple versions of APIs simultaneously allowing users to quickly iterate, test, and release new versions. Users and configure API gateways to route traffic to appropriate APIs version programmatically.
  • Configure security policies for APIs on a per API basis or API group basis

Mesh API gateway enables users to easily manage their APIs and improve the efficiency of the onboarding of API-consumers. Users can define their APIs using openAPI specification (swagger) to easily create

  • Catalog of all published APIs
  • Documentation
  • Sample code

Furthermore, users can configure base_api_url_path and prefix rewrite to easily create multiple API portals. This is useful when users wish to follow the CI/CD development process for their API development as well and want an API portal for dev/stage/production stages as an example. The API portal could have a different domain name in each stage of the development process. The system can automatically create API groups and base URL path mappings based on tags assigned by users to their API definition files.