Using Azure Front Door to Host an Embedded App on the Same Domain

An embedded app can run separately from an intranet and still appear under the intranet’s domain. For one client, we used Azure Front Door to route an existing intranet, a React iframe app, and its Fastify API through a single HTTPS entry point. Each service kept its own deployment, while the browser saw one origin.

The client already used Azure. Adding another edge provider would have introduced another vendor to configure and operate; hosting our own reverse proxy would have added a production service to maintain. Front Door fit this environment.

How the paths fit together

The intranet handles the catch-all route; the embedded app, its assets, and the API have specific routes.

/portal-app/* serves the React app from Azure Static Web Apps.

/portal-assets/assets/* serves its built JavaScript and CSS.

/portal-api/* reaches the Fastify API on Azure Container Apps.

/training-links/* reaches training short-link endpoints. Other paths go to the existing intranet.

Front Door selects a route using the request domain and path, with more specific path matches taking precedence over a catch-all. Its rule sets can rewrite a public path to the path expected by an origin. Configure each origin host header for the backend that actually serves the request.

Rewriting the path sent to an origin does not change the URL in the browser. That distinction lets the iframe and API keep their public paths while each backend receives a path it understands.

Making the asset path explicit

The app entry route and the asset route need separate checks. With Vite, a public base path can put built asset URLs under the path Front Door routes to Static Web Apps.

import {defineConfig} from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  base: '/portal-assets/',
  plugins: [react()],
})

With the normal Vite output structure, this yields browser requests such as /portal-assets/assets/index-abc123.js. Front Door can route that prefix to Static Web Apps and rewrite it to the asset path served at the origin. Test index.html, refreshed deep links, and asset URLs against the deployed build. An app route that returns index.html for every request needs an explicit client-side navigation strategy.

What the same origin did for authentication

The app and API appear to the browser under https://workspace.example.com. The frontend can call a relative URL instead of a separate API hostname:

async function getAppToken() {
  const response = await fetch('/portal-api/session/token', {
    credentials: 'same-origin',
  })

  if (!response.ok) throw new Error('Could not establish an app session')
  return response.json() as Promise<{accessToken: string}>
}

Same origin routing does not authenticate the caller. The API must validate the existing intranet session using an approved integration, check the user’s authorization, and only then issue its own short-lived bearer token. The frontend does not need to read an HttpOnly session cookie in JavaScript.

Cookie scope matters. A cookie restricted to an intranet only Path will not be sent to /portal-api/ merely because both paths share a hostname. Check Domain, Path, Secure, HttpOnly, and SameSite behavior with the real iframe and login flow before relying on this exchange.

Why a separate Azure sign-in is awkward inside an iframe

An alternative would have been to ask the embedded app to start its own Microsoft Entra ID sign-in. That is difficult to rely on inside an iframe: Entra ID does not render interactive sign-in prompts there, and MSAL blocks full-frame redirects by default. Silent APIs can work when the necessary account and session context is available, but they are not a guarantee. Consent, MFA, an expired session, or browser restrictions can require user interaction. Microsoft recommends a popup for interactive sign-in from an iframe, subject to browser and iframe sandbox rules.

The iframe and API sharing the intranet hostname does not make the Microsoft identity provider same-origin with them. Silent sign-in can still depend on identity-provider cookies in a third-party context, which some browsers restrict. Rather than make a second silent Entra sign-in the required path, this design used the existing intranet session as the starting point for an API-side token exchange. The API still has to validate that session and the user’s authorization. Confirm the actual validation mechanism with the project team before publication.

Rewriting and caching are separate decisions

Front Door also handled HTTPS redirects and path rewriting for this deployment. Project notes say caching was disabled on the app and API routes but enabled on the intranet catch-all. We would review the catch-all before treating that configuration as safe for every intranet response.

Microsoft recommends separating static and dynamic routes and disabling caching for authenticated API traffic. Personalized intranet HTML and session related responses require the same deliberate review: misconfigured edge caching can share one user’s content with another.

Checks before release

Confirm the intranet’s iframe and content security policy permit the intended embed. Test the cookie scope and token exchange in a real signed-in browser. Verify app entry, deep-link refresh, JavaScript and CSS assets, API endpoints, short links, HTTPS redirects, and catch-all routing. Repeat cache tests with two different signed-in users.

Finally, assess whether origins can be reached directly around Front Door. Azure documents Front Door-specific access controls for Static Web Apps; choose the equivalent controls supported by each origin rather than assuming routing alone closes the bypass.

The result was a shared browser facing origin without another edge provider or a reverse proxy we would need to run. The security boundary still lived in the API: it had to verify the intranet session before granting access to the embedded app.