Azure Static Web Apps Free: built-in Microsoft authentication callback returns HTTP 401

1. Yes. The documented authentication and authorization features are available in all Azure Static Web Apps plans. Built-in authentication supports Microsoft Entra ID, and custom roles are supported through route rules plus role assignment mechanisms such as invitations. The provided documentation does not state that a Microsoft Entra premium license is required for Static Web Apps built-in authentication.
2. The supported way to separate provider-authentication behavior from app authorization is to distinguish these endpoints and outcomes:
   1. Provider sign-in uses /.auth/login/aad for Microsoft Entra ID.
   2. The authentication callback endpoint for Entra ID is https://<YOUR_SITE>/.auth/login/aad/callback.
   3. App authorization is enforced by route rules in staticwebapp.config.json, such as allowedRoles.
   A callback 401 occurs in the authentication flow before route authorization to protected app content. A route-level 401 occurs when a request matches a protected route and the signed-in user does not have one of the required roles. For owner-only access, a route like this requires the assigned custom role:

      {
        "route": "/admin*",
        "allowedRoles": ["administrator"]
      }
   

   If the goal is to verify authentication separately from the custom owner role, the documented supported configuration is to temporarily protect a route with the built-in authenticated role instead of the custom role. That confirms sign-in independently of invitation-based role assignment.
3. Yes. The selected identity configuration can cause this if the app relies on the preconfigured Microsoft Entra provider while expecting tenant restriction. The preconfigured Microsoft Entra ID provider allows any Microsoft account to sign in. To restrict sign-in to a specific Microsoft Entra tenant, the documented supported correction is to configure a custom Microsoft Entra ID provider. For custom Entra configuration, the callback uses the same documented callback pattern and aad as the provider name placeholder for Entra ID. Also, if a custom provider is registered, all preconfigured providers are disabled. Since no custom provider is configured in this scenario, built-in providers remain active unless explicitly blocked by route rules. The context also contains a Microsoft Q&A case showing a known issue where some newer deployments were routed to an unhealthy identity backend and authentication failed with 401 on the callback, while later deployment to a healthy backend succeeded. That indicates identity backend behavior can also cause callback 401 independently of app route authorization.
4. Without premium licensing, the supported diagnostics in the provided material are:
   1. Validate the auth flow endpoints directly:
      • Login: /.auth/login/aad
      • User details: /.auth/me
      • Logout: /.auth/logout
      • Purge user details: /.auth/purge/aad
   2. Validate route behavior through staticwebapp.config.json rules and responseOverrides.
   3. Reproduce locally with the Static Web Apps CLI emulator using npx swa start, which provides a local sign-in page and role emulation.
   The provided material does not document additional Entra sign-in log diagnostics for non-premium tenants.
5. A supported owner-only alternative without weakening direct-route and static-asset protection is:
   1. Keep route protection in staticwebapp.config.json using allowedRoles so protection is enforced server-side for HTTP requests.
   2. Use a custom Microsoft Entra ID provider if sign-in must be restricted to a specific tenant.
   3. Assign the owner-only custom role through the documented invitations system or programmatically at sign-in with an API function.
   For whole-app protection, the documented pattern is:

      {
        "routes": [
          {
            "route": "/*",
            "allowedRoles": ["authenticated"]
          }
        ],
        "responseOverrides": {
          "401": {
            "statusCode": 302,
            "redirect": "/.auth/login/aad"
          }
        }
      }
   

   Then replace authenticated with the owner-only custom role after authentication is confirmed. This preserves server-side protection of direct routes and static assets. The documentation also warns that routing rules secure HTTP requests served by Static Web Apps, while sensitive data for client-side routes should be protected through APIs that validate identity.

References:

• Authenticate and authorize Static Web Apps
• Custom authentication in Azure Static Web Apps
• Configure Azure Static Web Apps
• Add authentication to your static site in Azure Static Web Apps
• Tutorial: Assign custom roles with a function and Microsoft Graph (preview)
• We are having some issues with the built in auth for static web apps - it only affects apps deployed in the last 48 hours - Microsoft Q&A