API Security: Rate Limiting & JWT Validation

1. The Power of the Policy Engine

Before we write any policies, it's crucial to understand their role. Policies are snippets of XML that execute in the request/response pipeline. They allow you to modify the behavior of your API at the gateway without touching a single line of your backend code. This is fundamental to the abstraction that APIM provides.

Policies are applied in different sections of the pipeline:

• inbound: Policies that execute on the incoming request before it's sent to your backend.
• backend: Policies that execute just before the request is forwarded.
• outbound: Policies that execute on the response coming back from your backend before it's sent to the client.
• on-error: Policies that execute if an error occurs.

Today, we will focus entirely on the inbound section to validate requests before they consume your backend resources.

Let's watch a brief conceptual overview of how this policy engine works.

2. Controlling Traffic with Rate Limiting

The first policy we'll implement is for rate limiting. This is a crucial defense against both accidental and malicious overuse of your API, ensuring it remains available and performant for all consumers.

APIM offers two primary policies for this:

• rate-limit: Applies a single rate limit to all calls for a given scope (e.g., all operations in an API).
• rate-limit-by-key: Applies a rate limit based on a specific key, allowing you to set different limits for different users, subscription keys, or IP addresses.

Let's explore how to configure this.

Hands-On: Apply a Rate Limit

Now, let's apply this to the API you configured in the previous lesson.

1. Navigate to your APIM instance in the Azure portal.
2. Select your API under the APIs blade.
3. Choose an operation, for example, the GET /WeatherForecast operation.
4. In the Inbound processing section, click the </> icon to open the policy code editor.
5. Within the <inbound> element, add the following policy. This policy allows only 3 calls every 60 seconds.

<policies>
    <inbound>
        <base />
        <rate-limit calls="3" renewal-period="60" />
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

6. Click Save.
7. Go to the Test tab for that operation and click Send four times in quick succession. The first three calls should succeed with a 200 OK status. The fourth call should fail with a 429 Too Many Requests status.

This simple exercise demonstrates how effectively you can protect your backend with just a few lines of configuration.

3. Securing Your API with JWT Validation

While subscription keys offer a basic level of security, modern applications typically rely on OAuth 2.0 and JWT bearer tokens for authentication. Given your background with REST APIs, you're likely familiar with this pattern. APIM can offload the entire token validation process from your backend service.

The validate-jwt policy is incredibly powerful. It can:

• Check for a valid token in the Authorization header.
• Verify the token's signature against the identity provider's public keys.
• Validate standard claims like issuer (iss), audience (aud), and expiration time (exp).
• Check for the presence of custom claims (e.g., roles or permissions).

The complete flow looks like this:

We'll use Microsoft Entra ID as our identity provider. To implement this, you'll perform two main tasks:

1. In Microsoft Entra ID: Register two applications—one to represent your API and one to represent the client application that needs to access it.
2. In Azure APIM: Configure the validate-jwt policy to validate tokens issued for your API.

The following video provides a clear, step-by-step demonstration of this entire process. We will follow it closely.

Hands-On: Implement JWT Validation

It's time to put this all together. Follow the steps from the video to secure your own API.

1. Create App Registrations:

   • In the Microsoft Entra ID section of the Azure portal, create two app registrations as shown in the video.
   • For the API app registration, go to Expose an API and set the Application ID URI. Copy this URI for later.
   • For the client app registration, go to API permissions, add a permission, find your API app registration under "My APIs", and grant the permission. Also, create a client secret and copy its value immediately (it won't be shown again).

2. Configure the Policy:

   • Navigate back to your API in APIM and open the policy editor for the desired scope (e.g., the whole API).
   • Add the validate-jwt policy inside the <inbound> section. Use the following template, replacing the placeholder values with your own.

<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
    <openid-config url="https://login.microsoftonline.com/{your-tenant-id}/v2.0/.well-known/openid-configuration" />
    <audiences>
        <audience>{your-api-application-id-uri}</audience>
    </audiences>
</validate-jwt>

*   You can find your **Tenant ID** on the overview page of your Microsoft Entra ID.
*   The `{your-api-application-id-uri}` is the URI you copied from the API app registration.

3. Test with Postman:
* Follow the video's instructions (starting at 11:17) to configure Postman to get an access token.
* Token URL: https://login.microsoftonline.com/{your-tenant-id}/oauth2/v2.0/token
* Client ID: The Application (client) ID of your client app registration.
* Client Secret: The secret value you copied from the client app.
* Scope: {your-api-application-id-uri}/.default
* Get the token, then use it as a Bearer Token in the Authorization header to call your APIM endpoint. You should receive a 200 OK. Try calling it without the token to confirm you get a 401 Unauthorized.

For detailed documentation on all the available attributes and child elements of the validate-jwt policy, you can refer to the official Microsoft Learn page validate-jwt - Azure API Management policy reference. It's a useful resource for more advanced scenarios.

Conclusion

Excellent work! You have now used APIM policies to add two critical layers of control to your API without modifying the backend service. This demonstrates the core value of an API Gateway in a modern architecture.

Key Takeaways:

• Policies are XML snippets that execute in the APIM request/response pipeline to modify API behavior.
• The <inbound> section is used to apply logic to incoming requests, such as validation and security checks.
• The rate-limit policy is a simple and effective way to protect your backend from being overwhelmed.
• The validate-jwt policy offloads complex token validation from your backend, enforcing authentication at the gateway using standard protocols like OAuth 2.0 and OpenID Connect.

Next Steps

Now that you can control who can call your API and how often, the next step is to control what they see and how the request is structured. In our next lesson, we will explore policies that transform requests and responses, such as modifying headers, rewriting URLs, and changing the response body. This will further enhance the abstraction between your clients and your backend services.