This article evaluates the available options for hosting a static website within a Microsoft 365 / Azure environment, where access must be restricted to company users via Microsoft Entra ID (formerly Azure Active Directory) — with no custom authentication code.
The target scenario has the following constraints:
dev.site.com, feature-xyz.site.com).Four realistic approaches exist within the Microsoft ecosystem. Each is examined below.
Azure Static Web Apps (SWA) is a purpose-built Azure service for hosting static sites and single-page applications. It has first-class GitHub integration and built-in authentication.
SWA provides a built-in authentication layer that requires zero application code. The free plan includes a pre-configured Microsoft Entra ID provider that allows any Microsoft account to sign in. The Standard plan ($9/month per app) unlocks custom authentication, which lets you restrict access to a specific Entra ID tenant by configuring staticwebapp.config.json:
openIdIssuer to https://login.microsoftonline.com/YOUR_TENANT_ID/v2.0 to lock down to your organisation.SWA natively supports branch preview environments. When a branch is pushed, a preview is deployed at <DEFAULT_HOST>-<branch>.<LOCATION>.azurestaticapps.net. Pull requests also get ephemeral preview URLs. The Free plan allows 3 staging environments; Standard allows 10.
Limitation: Custom domains (e.g., dev.mysite.com) cannot be assigned to preview environments. Only the production environment supports custom domains. Preview environments use the auto-generated azurestaticapps.net subdomain.
SWA provides an official GitHub Action (Azure/static-web-apps-deploy) that handles build and deploy. It is automatically generated when you link a GitHub repo during SWA creation.
Azure Storage accounts can host static websites directly from the $web blob container. Azure Front Door sits in front as a CDN and reverse proxy.
Blob Storage's static website feature serves content anonymously — there is no built-in authentication. To add Entra ID authentication, you must place Azure Front Door Premium in front and configure it to require Entra ID login before serving content. This is significantly more complex than SWA's built-in approach and involves configuring Front Door rules, Private Link to the storage account, and Entra ID app registrations manually.
Not built-in. You would need to create separate storage accounts or containers per branch and manage routing through Front Door rules or Azure DNS — all custom automation.
Azure App Service is a fully managed platform for web applications. It includes Easy Auth (Authentication / Authorization), a built-in module that handles authentication at the platform level without any application code.
Easy Auth supports Microsoft Entra ID out of the box. You configure it in the Azure Portal — select “Microsoft” as the identity provider, choose your tenant, and the platform handles login, token validation, and session management. No code changes. This is battle-tested and widely used.
App Service supports deployment slots (Standard tier and above, ~$70/month). Slots are designed for staging/production swaps, not per-branch environments. You could create one slot per branch, but the slot limit is typically 5–20 depending on tier, and it requires custom automation.
SharePoint Online is included in most Microsoft 365 plans. It can host pages and documents accessible to organisation users.
Authentication is fully handled by Microsoft 365 — users log in with their Entra ID credentials. This is as “native Microsoft” as it gets. Access can be scoped to the entire organisation or specific security groups.
Not applicable. SharePoint is a content management platform, not a deployment target for CI/CD pipelines.
.aspx pages or SharePoint Framework (SPFx).| Criterion | Azure Static Web Apps | Blob + Front Door | App Service + Easy Auth | SharePoint Online |
|---|---|---|---|---|
| Entra ID auth (no code) | Yes (Standard plan) | Via Front Door Premium | Yes (Easy Auth) | Yes (built-in) |
| Tenant restriction | Yes (config file) | Yes (manual setup) | Yes (portal config) | Yes (default) |
| Per-branch previews | Native (3–10 envs) | Custom only | Slots (limited) | No |
| Custom domain on previews | No | Possible (manual) | Possible (manual) | N/A |
| GitHub Actions support | Official action | Custom workflow | Custom workflow | No |
| Monthly cost | $0 (Free) / $9 (Standard) | ~$335+ | $13–$70+ | Included in M365 |
| Setup complexity | Low | High | Medium | Low (but limited) |
| Static site fit | Excellent | Good | Acceptable | Poor |
Azure Static Web Apps (Standard plan) is the clear winner for this scenario.
It is the only option that satisfies all requirements — Entra ID tenant-restricted authentication with no custom code, native GitHub Actions deployment, and built-in per-branch preview environments — at a cost of just $9/month.
The one caveat is that preview environments cannot have custom domains (e.g., dev.mysite.com). They use auto-generated azurestaticapps.net subdomains instead. For most teams, this is an acceptable trade-off given the simplicity of the setup.
If custom domains on preview environments are a hard requirement, you would need to layer Azure Front Door on top, or deploy separate SWA instances per environment — both of which add complexity and cost.
For a step-by-step implementation guide, see Tutorial: Azure Static Web Apps with Entra ID Authentication from Scratch.
Last updated: April 2026