Rate limiting in Azure API Management using custom API claims

Azure API Management (APIM) has become a first-class citizen in modern architecture. One of its most powerful functionalities is the policy engine, which allows you to enforce different controls before a caller’s request hits your backend services.

The purpose of rate limiting is to prevent excessive consumption of your APIs. This protects against D(DOS) types of attacks as well as accidental abuse of APIs. You make use of such policies to maintain a sustainable workload against your backends.

Microsoft documents the use of these policies here https://learn.microsoft.com/en-us/azure/api-management/api-management-sample-flexible-throttling. Typical scenarios for rate limiting are:

• Per-subscription key throttling
• Per-custom key throttling
• Per-app-or-user throttling, based on an incoming access token

Let us focus on the latter! In the official doc, you can see an example showing how to apply to throttle against individual users:

Figure 1 – User-based throttling

The incoming access token is extracted from the Authorization HTTP request header, then converted as a JWT token, and the Subject claim (sub in the token), is used as a key. The above policy allows for a maximum of ten calls per minute per user. So far so good, but have you ever tried to apply throttling against another attribute than the subject? You will have a tough time trying to find such an example in the Microsoft doc…

If you happen to have such a need, here is the tip:

You must target the Claims property of the JWT object to drilling down into the actual claims that are present in the token. The above example throttles a call based on the client app that was registered for a given consumer. This is somehow like the subscription-key-based throttling but with a stronger authn/authz mechanism. You can use this against any standard or custom claim you have in your token. Of course, as a best practice, you should define the claim name in a named value and use that named value in your policy.