top of page
Search

The Hidden Steps Microsoft Forgot to Document: Securing Azure App Service Authentication Behind Front Door with Private Link

  • Writer: Sebastian F. Markdanner
    Sebastian F. Markdanner
  • 2 days ago
  • 7 min read

Today I want to walk through how to configure Azure App Service Authentication when your App Service sits behind Azure Front Door and is accessed through a Private Link.

Azure diagram showing "Azure Front Door" connecting to "Azure App Service" via "Private Link" with security icon, on a blue tech background.

On a dreadful day in october 2025, I received something that most IT people fear - a request from a client!


The request included information from the client, that they were struggling with authentication on a Web App deployed behind Azure Front Door using Private Link. What looked like a straightforward setup quickly turned into a surprisingly tricky problem, mostly due to missing or incomplete documentation.


After digging into the issue, reproducing it in a separate environment, and spending more time troubleshooting than I’d like to admit, I decided to document the actual working solution here.


Table of Contents


The Authentication Issue

The client reported that after enabling authentication on the Web App and disabling public access, they consistently landed on an “access denied” page. Sometimes it showed a blue 403 screen; other times it was just a blank page with the message “You cannot access this resource.”


When I was first pulled into the issue, I couldn’t make sense of it. Based on the configuration, everything should have been working normally. So I went through the usual checklist:


✅ Microsoft Entra configured as the identity provider on the Web App

✅ Managed Private Link to Azure Front Door approved under the Web App’s networking settings

✅ Redirect URI configured in the App Registration used for the IdP configuration

✅ Redirect URI to the Front Door configured in the Web App’s authentication settings


Everything looked correct on paper.


To validate the issue, we tried reproducing the setup in our own environment — and sure enough, we hit the exact same error pages:

Blue background with white text: "Error 403 - Forbidden. The web app you have attempted to reach has blocked your access." Mood is restrictive.

At this point, the behavior technically made sense: public access was disabled on the Web App, and Azure Front Door wasn’t properly involved in the authentication flow. So the Web App was simply rejecting the request before authentication could even happen.


The confusing part was that nothing in Microsoft’s documentation suggested that the setup required anything beyond what we had already configured.


We tried several variations of the setup and saw inconsistent results, sometimes no authentication flow at all, sometimes we got the authentication prompt but were blocked afterward, and occasionally we were blocked immediately without any prompt.


After a lot of google-fu, trial and error, and rebuilding the entire setup more than once, we finally landed on a configuration that provided a consistent authentication experience, even with public access fully disabled, through the


To save others from the same pain, let’s walk through the exact solution.




Configuring Azure App Service Authentication Behind Azure Front Door

Setting up authentication for an Azure App Service behind Azure Front Door sounds straightforward on paper but in reality, it involves a series of configurations across Azure Portal, your DNS registrar, and even a manual JSON update. Below is the complete walkthrough, starting from a clean deployment and building toward the final working solution.


Initial configuration

To illustrate the process clearly, I’m starting with a fresh Azure App Service and a new Azure Front Door instance, following Microsoft’s recommended deployment pattern before adding the missing pieces.


Create the App Service

  1. Within the Azure Portal search for App Services.

    Click on it, and choose +Create to begin creating a new Web App.

    Azure portal interface showing a search for "App Services," displaying options like Function App, with a blue and white theme and navigation links.

  2. Fill in the required fields for the Web App.

    Note: The minimum required SKU for this scenario is Premium.

    Azure dashboard showcasing a web app creation page with details like subscription ID, resource group, and settings options against a white backdrop.

  3. Once the Web App is created, go to Authentication, then select Add identity provider.

    Web app interface titled "Authentication." Button "Add identity provider" highlighted, sidebar with options such as "Environment variables."

  4. Once the Web App is created, go to Authentication, then select Add identity provider.

    Form to add an identity provider with options for tenant type, app registration, and account types. Selected: Microsoft, workforce config.
    App settings interface showing options for client application, identity, and tenant requirements. Authentication settings require it, with a 302 redirect.


Create and Connect Azure Front Door

With authentication enabled on the Web App, the next step is to create (or connect an existing) Azure Front Door directly from within the Web App. This ensures the correct association and helps streamline the Private Link integration.


  1. Within the web app navigate to Networking, then under Optional inbound services, click View details

    Web app networking page showing inbound/outbound traffic settings. "View details" link highlighted. "Networking" option selected in menu.

  1. Either create a new Front Door or select an existing one, then fill out the required configuration.

    Azure setup screen for creating a new Front Door profile. Options for profile name, endpoint, and pricing tier are shown with a submit button.

  1. After Azure finishes deploying, or as I like to call it, after a “Microsoft Minute™️”, head back to the Web App to approve the Private Endpoint connection under Networking.

    Azure networking settings screen showing inbound and outbound traffic configurations. "1 private endpoint" highlighted in red.
    Dialog box prompts to approve a private endpoint connection in an online portal. Options are Yes or No. Connection details shown below.

Disable Public Access

  1. Next, restrict direct access to the Web App. Go to Access Restrictions and disable public access

    Network settings screenshot showing "Inbound traffic configuration" with public access enabled, no restrictions. Includes 1 private endpoint.
    Network access panel with "Disabled" selected in settings. Options for enabling from all networks or select networks. Blue and white design.

At this point, the App Service and Front Door are configured and linked, but authentication still won’t work as expected when accessed through Front Door with Private Link. Normally, you would add the Front Door hostname as a redirect URI in both the App Registration and the Web App authentication settings, and while that is part of the final configuration, it’s not enough on its own.


Before updating any authentication settings, we’ll walk through the additional steps required to get a fully working solution without redoing work later.



Addition configuration for working solution

To get authentication flowing correctly through Azure Front Door while the Web App remains private, several more configurations are required. These are the parts the documentation doesn’t cover.


Here’s the full list of what we’ll configure:


  • Add custom domains to both the Web App and Front Door (same root domain)

    • Example:

      • webapp.chanceofsecurity.com

      • frontdoor.chanceofsecurity.com

  • Add the Front Door domain to CORS

  • Add the Front Door domain to the Web App authentication configuration

  • Update redirect URIs in the App Registration

  • Update the authsettingsV2.json forward proxy setting on the Web App


Once these are in place, the authentication flow works through Front Door, even with public access disabled.


Let’s walk through each step in detail.


Adding custom domains

  1. In the Web App, go to Custom domains and click Add custom domain.

    Web app interface showing custom domains. "Add custom domain" is highlighted. Status is secured. IP address and verification ID visible.

  1. Enter the custom domain. In this example, I’m using an external registrar with a managed certificate. Azure provides the DNS records you’ll need to add..

    Custom domain setup screen showing options for domain provider and TLS/SSL certificates. Domain name input is "webapp.chanceofsecurity."

  1. Add the DNS records to your registrar and wait for validation.

    Form to add a DNS record displays fields for Type, TTL, Name, and Value, with a light blue info box below detailing DNS change effects.

  1. Next, switch to Azure Front Door. Go to Domains and click Add a domain.

    Azure portal interface showing "Domains" section. Message: "No domains match your filters." Button: "Add a domain" highlighted in blue.

  1. Choose the domain and click Add

    Azure interface displaying "Add a domain" options. Domain type, DNS management, and HTTPS settings are selected. Text includes a warning notice.

  1. The domain will appear in a pending state. Click the Validation state to view the DNS records required for validation

    Dashboard interface showing domain management. "frontdoor.chanceofsecur..." domain succeeded, pending validation. "Domain validation needed".
    Microsoft Azure screen for DNS validation with instructions, record type TXT, name, and value. Regenerate button is shown.

  1. Add the corresponding TXT and CNAME records in your DNS registrar again and wait for propagation

    DNS record addition form showing fields for Type, TTL, Name, and Value. Text indicates changes take 1-24 hours to take effect.

  1. Once validated, associate the newly added custom domain with your desired Front Door endpoint and route

    Azure interface to associate domains with endpoints and routes. Domain: frontdoor.chanceofsecurity.com. Endpoint, route fields shown.


Adding Front Door domain within the CORS config

To allow the authentication flow to redirect through Front Door, the domain must be listed in CORS.


In the Web App, open CORS and add the Front Door custom domain to Allowed Origins.

Web app interface showing CORS settings with options to enable credentials and specify allowed origins. Text and icons are visible.


Updating the Authentication settings on the Web app

In the Web App, go back to Authentication and select Edit on the authentication configuration.


Add the Front Door custom domain to Allowed external redirect URLs.

Web app authentication settings screen with options for enabling authentication, restricting access, and setting redirect URLs. Save button highlighted.


Updating the Microsoft Entra App Registration

Next, update the redirect URIs for the application registration automatically created during IdP setup.


Navigate to Microsoft Entra -> App registrations, search for the Web App’s name, and open it.


Go to Authentication and replace the existing redirect URIs with your Front Door domain using this format:

https://<frontdoor.chanceofsecurity.com>/.auth/login/aad/callback

Platform configurations screen showing web redirect URI settings, logout URL input, and save/discard buttons. Blue-white theme.




Configure the Forward Proxy Setting (authsettingsV2.json)

This step is critical - and undocumented. The authentication flow only works behind Front Door + Private Link when the forwardProxy.convention is set to "Standard".


If any configuration change is made in the Web App afterward, this setting resets, so it must be applied last.


Run the following PowerShell snippet, either locally or for ease of use, from the Azure Cloud Shell:

# Variable configurations
$subid = (Get-AzSubscription).id
$rg = <resourcegroup-name>
$webapp = <webapp-name>

# Get current configuration
$current = az rest --method get --url "https://management.azure.com/subscriptions/$subid/resourceGroups/$rg/providers/Microsoft.Web/sites/$webapp/config/authsettingsV2?api-version=2020-09-01" | ConvertFrom-Json

# Update proxy setting
$current.properties.httpSettings.forwardProxy.convention = "Standard" 

# Convert updated config to json
$body = $current | ConvertTo-Json -Depth 100  

# Update config
az rest --method put --url "https://management.azure.com/subscriptions/$subid/resourceGroups/$rg/providers/Microsoft.Web/sites/$webapp/config/authsettingsV2?api-version=2020-09-01" --body $body

After this change, authentication will finally work through Front Door with Private Link and the Web App locked down!


Web app status page with Microsoft Azure logo. Text: "Your web app is running and waiting for your content." Options for deployment or quickstart.


TL;DR Configuration steps

If you just need the quick reference, here’s the full sequence of steps required to get Azure App Service authentication working behind Azure Front Door with Private Link:


  1. Create the Azure Web App and Azure Front Door

  2. Associate the Web App with Front Door (via Optional Inbound Services / Private Link)

  3. Disable public access on the Web App via Access Restrictions

  4. Add Microsoft Entra as the identity provider on the Web App

  5. Configure custom domains on both the Web App and Front Door (same root domain)

  6. Update the Entra App Registration with the Front Door custom domain as a redirect URI

  7. Update the Web App authentication settings to include the Front Door domain as an allowed redirect

  8. Add the Front Door custom domain to CORS on the Web App

  9. Update authsettingsV2.json and set the convention:

httpSettings.forwardProxy.convention = "Standard"


Conclusion

That brings us all the way from the initial “Why is nothing working?” moment to a fully functional, secure authentication flow running through Azure Front Door with Private Link.


The setup itself is not inherently complicated, it’s the missing documentation and the unexpected extra steps that make the journey confusing. Once the custom domains, redirect URIs, CORS configuration, and the forward proxy setting are aligned, the whole flow snaps into place and works exactly as you’d expect.


Now for the mandatory bad joke to break from the headaches this problem have caused!


I told my wife she should embrace her mistakes...

She turned and gave me a hug! 😎


With everything configured correctly, you now get a properly locked-down App Service, seamless Microsoft Entra authentication, and a clean, controlled entry point through Azure Front Door without ever exposing the Web App publicly. If you’ve run into this issue before, hopefully this walkthrough saves you from the same troubleshooting loop.


If you ever run into the same issue, I hope this walkthrough saves you from the same troubleshooting maze.


Until next time stay tuned!

bottom of page