/.auth/ endpoints of static web app do not work after enabling custom mode (authentication)

Question

/.auth/ endpoints of static web app do not work after enabling custom mode (authentication)

Dhiogo Acioli 0

Error when enabling authentication in custom mode (static web app + Blazor WASM)

Two errors occur:

1 - The "/.auth/me" API doesn't return a JSON file, but rather my HTML page;

2 - When trying to log in (example: .auth/login/google), it finds nothing and triggers a "not found" error (Sorry, there's nothing at this address);

Note 1: It's worth noting that this error only occurs when I try to enable custom mode in Azure. If I leave it in simple mode, it works normally.

Note 2: These endpoints are from Azure (not mine), created exclusively and automatically for apps that are installed in the static web app.

SUNOJ KUMAR YELURU 15,811 Reputation points MVP Volunteer Moderator

2025-08-19T02:21:57.9366667+00:00
Hello @Dhiogo Acioli

After enabling custom authentication mode in Azure Static Web Apps, the built-in /.auth/ endpoints are disabled, requiring you to implement your own authentication flow using an identity provider like Google and manage user sessions with tokens

Evidence Analysis

First Argument: Custom authentication mode disables the default /.auth/ endpoints. Azure expects you to handle authentication logic, so requests to /.auth/me are routed to your app, and /.auth/login/google results in a "Not Found" error.

Second Argument: Implementing the authentication flow involves configuring an OAuth 2.0 application (e.g., Google), creating an API endpoint (Azure Function) to handle redirects and token generation, and updating the Blazor WASM app to initiate login, handle callbacks, and authorize API requests.

Third Argument: The routes.json file must be configured to route API requests to the backend and explicitly return a 404 for /.auth/* requests, ensuring that the custom authentication flow is correctly managed by your application.

Alternative Viewpoint 1: Using a different identity provider: The steps would be similar, but the configuration of the OAuth 2.0 application and the specific API calls would vary based on the provider (e.g., Microsoft, Facebook).

Alternative Viewpoint 2: Using a pre-built authentication library: Libraries like Microsoft.Identity.Web can simplify the implementation of the authentication flow, but still require configuring the identity provider and handling tokens.

If the Answer is helpful, please click Accept Answer and Up-Vote, so that it can help others in the community looking for help on similar topics.
Dhiogo Acioli 0 Reputation points

2025-08-19T11:25:33.8+00:00

Wait, since when was this rule enforced? Are you sure, or is it just a guess?

Static web apps were created to facilitate website development and deployment, and doing things yourself breaks this principle.

The documentation itself makes it clear that the rules remain the same: https://learn.microsoft.com/en-us/azure/static-web-apps/authentication-custom?tabs=aad%2Cinvitations

I tested this a month ago, and it was working normally. So, we only have two hypotheses:

1 - This rule was enforced this month, and the documentation hasn't been updated (unlikely);

2 - Some external service was modified and directly affected the static web app (I think it's very likely, since this service hasn't had an active development team for a year);

Your answer

SUNOJ KUMAR YELURU 15,811 Reputation points MVP Volunteer Moderator

2025-08-19T02:21:57.9366667+00:00

Hello @Dhiogo Acioli

After enabling custom authentication mode in Azure Static Web Apps, the built-in /.auth/ endpoints are disabled, requiring you to implement your own authentication flow using an identity provider like Google and manage user sessions with tokens

Evidence Analysis

First Argument: Custom authentication mode disables the default /.auth/ endpoints. Azure expects you to handle authentication logic, so requests to /.auth/me are routed to your app, and /.auth/login/google results in a "Not Found" error.

Second Argument: Implementing the authentication flow involves configuring an OAuth 2.0 application (e.g., Google), creating an API endpoint (Azure Function) to handle redirects and token generation, and updating the Blazor WASM app to initiate login, handle callbacks, and authorize API requests.

Third Argument: The routes.json file must be configured to route API requests to the backend and explicitly return a 404 for /.auth/* requests, ensuring that the custom authentication flow is correctly managed by your application.

Alternative Viewpoint 1: Using a different identity provider: The steps would be similar, but the configuration of the OAuth 2.0 application and the specific API calls would vary based on the provider (e.g., Microsoft, Facebook).

Alternative Viewpoint 2: Using a pre-built authentication library: Libraries like Microsoft.Identity.Web can simplify the implementation of the authentication flow, but still require configuring the identity provider and handling tokens.

If the Answer is helpful, please click Accept Answer and Up-Vote, so that it can help others in the community looking for help on similar topics.
Dhiogo Acioli 0 Reputation points

2025-08-19T11:25:33.8+00:00

Wait, since when was this rule enforced? Are you sure, or is it just a guess?

Static web apps were created to facilitate website development and deployment, and doing things yourself breaks this principle.

The documentation itself makes it clear that the rules remain the same: https://learn.microsoft.com/en-us/azure/static-web-apps/authentication-custom?tabs=aad%2Cinvitations

I tested this a month ago, and it was working normally. So, we only have two hypotheses:

1 - This rule was enforced this month, and the documentation hasn't been updated (unlikely);

2 - Some external service was modified and directly affected the static web app (I think it's very likely, since this service hasn't had an active development team for a year);

Share via

/.auth/ endpoints of static web app do not work after enabling custom mode (authentication)

Your answer