Manual Chapter : API rate limiting: Customer ID based quota enforcement

Applies To:

Show Versions Show Versions

BIG-IP APM

  • 17.1.0, 17.0.0, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0
Manual Chapter

API rate limiting: Customer ID based quota enforcement

In this example of API rate limiting, each customer application gets its own request quota. The example uses two airline applications called Southwest and Alaska. The policy uses OAuth token validation, and branch logic is based on Client application ID using the key ClientAppID.
Each application has a different API rate limiting agent. The Southwest application is allowed up to 10,000 requests every 10 minutes, and Alaska allows up to 5,000 requests every 10 minutes. The API protection per-request policy checks the client application ID, and adds the request to the quota tally for that application.
To develop this example, you need to
  • Create an API protection profile that defines the paths, servers, and responses preferably using an OpenAPI spec file.
  • In the API protection profile, for
    Authorization
    , use
    OAuth 2.0
    .
  • On the Rate Limiting tab of the API protection profile, use the predefined identity key called
    ClientAppID
    in two rate limiting configurations that use different request quotas and spike arrest values for each airline.
  • On the Access Control tab, click
    Edit
    to see the visual representation of the per-request policy that was created.
  • In the visual policy editor, edit the policy as needed for rate limiting each application. Create API Rate Limiting agents for each application and in each agent, select the appropriate configuration and response for that airline.
Here is the example API protection per-request policy that performs different levels of rate limiting for two airline applications.

How it works

  1. Access Policy Manager receives an API request with an authorization header containing a JWT access token.
  2. The access token is extracted from the authorization header.
  3. For all API requests, the OAuth Scope agent in the subroutine validates the access token.
  4. If OAuth validation fails, the system returns an appropriate response for that API request.
  5. On successful validation of the JWT access token, the policy classifies the request based on the value of
    ClientAppId
    and sends it to the appropriate branch.
  6. By assigning different Rate Limiting configurations in the two API Rate Limiting agents, the policy enforces different rate limiting quotas for each airline.
  7. If the number of requests exceeds the quota, the system returns a response to the sender of the API request, and logs an error message.