Deploy an Azure Static Web App with Microsoft Entra SSO

Technical review: 26 October 2026. Product names, licensing references and procedures reflect this review; check the linked documentation for your release.

Hosting a static frontend is straightforward; making its sign-in boundary clear takes a little more design. Azure Static Web Apps is a separate product from App Service and Azure Storage static hosting. This guide outlines a tenant-specific Entra sign-in pattern for the Standard plan, not a universal configuration for every hosting service.

Prepare the hosting and identity pieces

Create the Static Web App in the approved subscription and resource group, then connect the supported deployment source and build settings. Record the app location, build output and environment. Confirm the published result before adding authentication, using a non-sensitive initial page.

For a custom Entra registration, create or select the appropriate single-tenant app registration. Configure the Web redirect URI for the actual hostname ending in /.auth/login/aad/callback. Record the application client ID and the related Enterprise Application. The app registration and its service principal are different objects; confusing their identifiers makes later troubleshooting harder.

Reference settings rather than publishing secrets

Custom authentication is configured in staticwebapp.config.json. Keep any credential value in the service’s protected application settings or a supported secret-management pattern, never in the repository. A minimal provider fragment looks like this:

{
  "auth": {
    "identityProviders": {
      "azureActiveDirectory": {
        "registration": {
          "openIdIssuer": "https://login.microsoftonline.com/<TENANT_ID>/v2.0",
          "clientIdSettingName": "ENTRA_CLIENT_ID",
          "clientSecretSettingName": "ENTRA_CLIENT_SECRET"
        }
      }
    }
  }
}

This is only the provider fragment. Merge it with the complete routing configuration and replace the tenant placeholder. The setting names must match the application settings exactly. Current Microsoft guidance also describes a managed-identity federation alternative for supported workforce configurations; evaluate that separately rather than assuming every deployment needs a long-lived secret.

Protect routes and assign the intended users

Add route authorization for the areas that require authentication and test the unauthenticated response. Ensure the configuration file reaches the root of the deployed build output. A file left only in the source tree may not be included by the build pipeline.

Use the Enterprise Application’s assignment settings and approved user/group assignments where required. An Azure Reader assignment lets someone inspect the hosting resource; it does not automatically authorize them to use the web application. Application roles and backend API authorization are separate again.

Test the boundary, not just the login screen

• An unauthenticated user cannot retrieve protected pages directly.
• An approved ordinary user can sign in and use the intended routes.
• An unassigned or wrong-tenant account receives the intended denial.
• Direct API requests enforce their own authorization rather than trusting a hidden navigation link.

Test preview environments and custom hostnames too; they can introduce additional callback and configuration questions. Preserve the previous deployment and identity settings for rollback, and record credential expiry or the chosen federation ownership. If access must also depend on network location, see IP restrictions and Conditional Access for the additional layer.

References

• Microsoft: custom Static Web Apps authentication
• Microsoft: configure Static Web Apps routing
• Microsoft: authentication and authorization in Static Web Apps