Azure Front Door Grows Up with gRPC Edge Actions and JWT Security

In this blog post Azure Front Door Grows Up with gRPC Edge Actions and JWT Security we will explain how Microsoft’s application delivery service is becoming more useful for modern APIs, AI services and customer-facing platforms.

Many mid-market businesses have reached an awkward stage. Their applications have grown beyond a single website, but their traffic management still relies on separate gateways, security tools and custom code that nobody wants to touch.

Azure Front Door sits in front of these applications and acts as a global entry point. It directs users to a healthy service, improves performance and can block malicious requests before they reach your systems. New support for gRPC, Edge Actions and JSON Web Token validation expands what can happen at that front door.

Why these changes matter to the business

Previously, Azure Front Door was mainly viewed as a global traffic manager, content delivery network and web application firewall. A web application firewall, or WAF, inspects incoming web traffic and blocks common attacks.

It was useful, but organisations often needed extra services or application code to manage modern API traffic, check access tokens or make more advanced routing decisions.

The latest capabilities allow more of those decisions to happen close to the user. That can reduce delays, lower the amount of unwanted traffic reaching your applications and simplify parts of the delivery architecture.

This does not mean Front Door replaces Azure API Management, application authentication or good software design. It means technology leaders have more choice about where each control should sit.

Native gRPC support improves modern service delivery

gRPC is a communication method commonly used between applications, microservices and AI agents. Instead of exchanging large, human-readable messages, it normally sends smaller binary messages over HTTP/2, which supports multiple conversations across one connection.

In business terms, gRPC can help internal services communicate efficiently. It is particularly useful when an application makes frequent calls between components or needs to stream information in real time.

Azure Front Door’s native gRPC support is currently in public preview. It can accept a gRPC connection at Microsoft’s edge, choose a healthy destination and forward the call to the application over a separate encrypted HTTP/2 connection.

Routes can be matched to a specific gRPC service or method. This gives teams more control over where calls go without exposing every backend service directly to the internet.

For example, a software company could direct inventory calls to a service in Melbourne while sending document-processing calls to a separate AI service. If an origin becomes unhealthy, Front Door can direct calls to another available origin.

Native gRPC health probes can also check whether a service is ready to receive traffic. This can reduce failed transactions and shorten recovery time during an outage.

Because gRPC support remains in preview, it should be introduced through a controlled pilot rather than moved immediately into a critical production path. Streaming behaviour, timeouts, monitoring and security policies all need to be tested using realistic traffic.

Edge Actions bring small decisions closer to users

Edge Actions allow lightweight JavaScript code to run at Azure Front Door locations around the world. The code can examine a request or response and make a quick decision before traffic continues to the application.

Useful scenarios include rejecting invalid requests, changing headers, rewriting an address, selecting an origin or directing a small percentage of users to a new application version.

Consider a 200-person company releasing a redesigned customer portal. Instead of building rollout logic into the portal, an Edge Action could direct five per cent of suitable requests to the new version.

If monitoring identifies a problem, the traffic can be returned to the stable version. The business outcome is a lower-risk release with less disruption for customers and support teams.

Edge Actions are deliberately small. Code is limited to 16 KB and must finish within 10 milliseconds. Up to three versions can be maintained, which supports controlled updates and rollback.

Those limits are a useful design signal. Edge Actions should make fast, predictable decisions. They should not contain complex business processes, call slow external systems or become another application that is difficult to maintain.

JWT validation can stop unsuitable requests earlier

A JSON Web Token, usually called a JWT, is a signed digital pass presented by a user, device or application. It can identify who issued the token, which service it is intended for and when it expires.

Edge Actions can examine these tokens and reject requests that do not meet defined requirements. For example, a request could be denied if the token is missing, expired or intended for a different application.

The high-level decision might look like this:

IF the request has no access token
 return 401 Unauthorized

IF the token is expired or for the wrong application
 return 403 Forbidden

OTHERWISE
 send the request to the selected healthy origin

This early screening can reduce unwanted load on APIs and application servers. It also provides a more consistent first check when several development teams are publishing services behind the same Front Door profile.

However, JWT validation at the edge should not become the only authentication control for sensitive systems. If Edge Action code exceeds its execution limit, Front Door can continue processing without that action.

Critical APIs should therefore validate identity again at the application or through a service such as Azure API Management. Edge validation is best treated as an additional checkpoint, not the sole lock on the door.

The same layered principle applies to partner integrations. Certificate controls covered in our Azure Front Door mutual TLS playbook can identify trusted partner systems, while tokens can control what those systems are permitted to do.

A practical architecture for a mid-market application

A sensible design separates traffic according to its purpose and risk rather than forcing every request through identical controls.

/public/* Website content and caching
/api/customer/* WAF, JWT checks and API controls
/grpc.Inventory/* Native gRPC routing and health probes
/admin/* Strong identity checks and tighter WAF policy

Public content can prioritise speed and caching. Customer APIs can receive token checks and rate limits. Administrative functions can have much stricter controls than general website traffic.

This builds naturally on route-level WAF policies, which let organisations apply different web application firewall protections to sign-in, payment, API and public routes.

For AI and agent-based applications, gRPC can also provide an efficient communication option between services. The surrounding controls remain important, as discussed in our guide to production-ready A2A agents on Azure Container Apps.

What should CIOs and CTOs ask their teams?

• Which services are publicly exposed? There should be a documented reason for every direct internet-facing origin.
• Where is identity actually validated? Edge screening must not accidentally replace application-level authentication.
• Are gRPC limitations understood? Preview features should have a rollback plan and production-like testing.
• Who owns Edge Action code? It needs version control, testing, approval and monitoring like any other code.
• Are Front Door and WAF logs enabled? Without usable logs, security incidents and failed requests are much harder to investigate.
• Is the design genuinely simpler? Adding another feature is only worthwhile if it reduces risk, cost or operational effort.

These capabilities can support broader Australian Cyber Security Centre guidance by reducing exposure and improving monitoring. They do not, by themselves, deliver Essential 8 compliance, which is the Australian government’s baseline cybersecurity framework covering areas such as patching, multifactor authentication and backups.

The opportunity is controlled simplification

Azure Front Door is growing from a global web entry point into a more capable application delivery layer. Native gRPC can improve modern service routing, Edge Actions can remove small decisions from backend applications, and JWT checks can filter unsuitable requests earlier.

The real benefit is not using every new feature. It is creating a simpler path from users to applications while keeping identity, security and failure controls clear.

As a Melbourne-based Microsoft Partner and Wiz Security Integrator, CloudProInc combines more than 20 years of enterprise IT experience with hands-on Azure, Defender, Wiz and application security work. We help organisations decide which controls belong at the edge and which should remain deeper in the application.

If you are unsure whether your current application delivery setup is protecting the business or simply adding cost and complexity, we are happy to take a practical look with you — no strings attached.