Authorisation configuration

There are two parts: page authorisation and user administration. And you can decide whether the authorisation is added in the source or as part of the publication process.

Page authorisation

If a website should be accessible by specific people only, then the authorisation should be configured as part of the staticwebapp.config.json file in the root of the website. In my projects I have either public websites (no authorisation) or websites that are accessible by authorised people where each has the same permissions. The configuration is similar to:

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

• The /login and /logout routes allow for user-friendly login and logout URL. All /.auth/* paths are part of Azure, and /.auth/login/aad is the credential provider for Entra ID and personal Microsoft accounts.
• The /* route specifies the role users must have to access all pages except the ones related to authentication. As all users are equal, there's only one role and it doesn't matter how it is called - but do not use one of the standard roles! The name of the role is case insensitive. The /* route does not block access to /.auth routes.
• The responseOverrides for 401 redirect every visitor to the login page.

Page authorisation automated

In my projects the authorisation is required only for one of the websites (the private one) or sometimes another (test environment), but the rest of the staticwebapp.config.json is the same. Instead of producing a separate staticwebapp.config.json per website, I leave the staticwebapp.config.json in the source git repository as it is for the public website. I've created a simple tool that can run as part of the publication pipeline, reads the staticwebapp.config.json file, adds the extra routes and 401 response override and overwrites the configuration file. The pipeline specification for a test environment would look like:

trigger:
  - main

pool:
  vmImage: windows-latest

steps:
  - checkout: self

  # Put tasks to create the website here

  - script: $(System.DefaultWorkingDirectory)/Tools/Authorise.exe -Role Welcome -ConfigFile $(System.DefaultWorkingDirectory)/wwwroot/staticwebapp.config.json

  - task: AzureStaticWebApp@0
    inputs:
      app_location: 'wwwroot'
      azure_static_web_apps_api_token: $(deployment_token)
      deployment_environment: Test

User administration

The only way to administer users is to invite them on a per-app basis. This is demonstrated in the next video.