What the authentication policy changes
The new policy puts a client-token check at Front Door’s edge. Microsoft’s security guidance describes configuring it on a Premium profile through the Azure portal, with clients presenting their token using the Bearer authentication scheme in the configured header.
Two modes determine what happens when validation fails:
- Block rejects requests that do not satisfy the policy.
- Log records validation results without blocking those requests.
That distinction matters during evaluation. A request reaching the application in Log mode does not establish that its token passed validation—the policy may have observed a failure and deliberately allowed the request through. Administrators should assess the recorded validation result, not just whether the application returned a page. This is a practical implication of the documented modes, rather than a separate Microsoft guarantee.
Two authentication checks, two different jobs
Client JWT validation should not be confused with Front Door’s managed identity origin authentication. Microsoft documents the latter as a separate preview in which Front Door obtains an Entra token to authenticate itself to supported backend resources. One checks the incoming client’s credential; the other establishes Front Door’s identity to the origin.
When both are used, header selection becomes operationally important. Microsoft’s Front Door FAQ advises placing the client token in Proxy-Authorization and reserving Authorization for the origin-authentication token. Both use the Bearer scheme. Otherwise, two credentials with different jobs compete for the same header—a small configuration detail with ample potential for a long troubleshooting afternoon.
A useful CLI detail for administrators
Microsoft’s Azure CLI reference provides another concrete planning point: az afd auth-policy belongs to the cdn extension and requires Azure CLI 2.85.0 or later. The reference says the extension installs automatically when the command group is first used, and marks the group as preview and under development.
The documented commands cover creating, listing, inspecting, updating, deleting, and waiting for authentication policies. Two creation defaults deserve particular attention:
| CLI setting | Documented default |
|---|---|
--action | Block |
--forward-token-to-origin | True |
These defaults mean an administrator seeking an observation-only experiment should explicitly select Log rather than assume it. Token forwarding also deserves an intentional decision based on what the backend expects. The CLI reference establishes these settings; it does not make them a substitute for testing the complete application path.
What to evaluate—and what to leave intact
A sensible nonproduction assessment would compare requests carrying an expected valid token, an invalid token, and no token, then verify the difference between Log and Block behavior. This is an evaluation recommendation inferred from Microsoft’s documented policy behavior, not a published Microsoft test checklist.
Keep the surrounding security architecture in view, too. Microsoft’s Front Door guidance separately recommends restricting direct access to origins, applying WAF protection, and avoiding unintended caching of sensitive authenticated content. An edge credential check does not make those concerns disappear.
The practical takeaway is straightforward: Front Door Premium customers can evaluate an additional Entra token-validation layer before traffic reaches the origin, while preserving backend authorization and existing production protections. Given Microsoft’s explicit preview warning, the right next step is a controlled trial—not a production security shortcut.