Authorisation

The principles

Static Web Apps support role-based authorisation. The end users of the website should be divided based on the role they have in the application. For each route or path of the web pages (that can include wildcards) the roles can be listed of the end users that have access to that page (or pages).There are standard roles, e.g., authenticated for all authenticated users.

Azure supports several providers of user credentials, including Azure's Entra ID (that supports personal Microsoft accounts) and Github. There are several options to customize this and add extra providers, but those are not included in the free/hobby plan. It is possible to exclude one or more of the standard providers (regardless of the plan).

Selected data for the authenticated user is available in the client-side application, but only after the user is authorised.

The real world

There are some limitations that make role-based authorisation less obvious than it seems.

The first is that you cannot use Entra ID as the ultimate user administration for the free plan. The only way to authorize users is to invite them individually, and you can do that for a maximum 25 users (per Static Web App, applicable to all plans).

Other plans allow for custom credential providers, but that also requires some thought. If you want to allow for personal Microsoft accounts, the standard Entra ID credential provider should be enabled, even though it does not use the Entra ID. Not sure whether and how you can assign a role to a user with a personal account. Standard roles like authenticated are not very useful for authorisation purposes, as everyone who manages to use one of the authentication providers to log in is an authenticated user.

By default the standard credential providers are enabled. That's fine for the Microsoft ones, like Entra ID - if you don't trust that, you wouldn't use Azure. Github is also acceptable, as it is also Microsoft. But twitter and later X was also enabled, and given its owner/CEO and his concerns for the well-being of its users/customers, that's not one I would trust. So I typically limit the providers to the ones that I really need.

Finally there is the way the role-based authorisation is implemented. It is specified per route, i.e., path to a web page; wildcards are allowed. The specification is part of a configuration file that has a maximum size of 20KB (in 2025). If you want to have per-page authorisation, you can't have a route per page unless the website is really small. You have to create a directory structure where you can specify the authorisation for a handful of directories.

The last issue made me decide to publish two websites, a public and a private one, rather than a single one with authorisation per routes. The configuration for the private one can be small and tight.