Intermittent per-user 403 from Azure App Service EasyAuth before requests reach the application

Question

We are investigating recurring HTTP 403 responses generated by Azure App Service built-in authentication (EasyAuth).

The issue has occurred on both the production app and its staging deployment slot. It affects one user at a time, persists for approximately 30 minutes, and then resolves automatically without a deployment, restart, or configuration change. Other users can continue using the service normally.

Architecture

• Frontend: React SPA using @azure/msal-browser
• Backend: Linux Azure App Service running Node.js/Express
• Authentication: App Service built-in authentication with Microsoft Entra ID
• The SPA obtains an access token for the backend API and sends it in the Authorization: Bearer header
• Production and staging use the same frontend client application but separate App Service endpoints

Observed behavior

For an affected request:

1. The browser sends a CORS OPTIONS request, which returns HTTP 200.
2. The subsequent authenticated GET request returns HTTP 403.
3. App Service HTTP logs classify it as CallerError.
4. The 403 response completes in approximately 2–14 ms.
5. The response body is empty.
6. There is no corresponding request in the backend Application Insights requests table.

This indicates that the request is rejected by EasyAuth before reaching the Node.js/Express application.

The affected endpoints are ordinary authenticated read endpoints, including:

• GET /api/v2/me
• GET /api/v2/view-management/profile
• GET /api/v2/announcements

During one staging incident, the failures persisted for approximately 32 minutes:

• /api/v2/me: 52 responses with HTTP 403
• /api/v2/view-management/profile: 14 responses with HTTP 403
• /api/v2/announcements: 50 responses with HTTP 403

A production incident showed the same pattern for approximately 31 minutes.

All observed failed requests were handled by the same App Service worker. This does not appear to be an IP access-restriction issue:

• App Service access restrictions allow all traffic.
• The CORS preflight succeeds.
• Other users continue to receive successful responses.
• The affected user eventually recovers without any server-side action.

Logs checked

We enabled the applicable App Service diagnostic categories and sent them to Log Analytics.

AppServiceHTTPLogs contains the platform-generated 403 responses, but does not include:

• EasyAuth rejection reason
• Token audience or authorized-party validation result
• Token hash
• User identity
• Authentication correlation ID

AppServiceAuthenticationLogs contains zero records for the incident windows. The authentication-log category is also not supported for the staging slot in our environment.

Backend Application Insights contains no matching 403 requests, confirming that the requests did not enter Express.

The frontend Application Insights shows successful calls to the Microsoft Entra token endpoint during the broader incident windows. However, the telemetry does not show which resource or scope each token request targeted, so it does not prove that a fresh backend API token was obtained.

Questions

1. What EasyAuth condition can cause one user’s authenticated GET requests to return 403 continuously for approximately 30 minutes and then recover automatically?
2. Is an empty, platform-generated 403 with Result=CallerError associated with a documented EasyAuth validation failure?
3. Why might AppServiceAuthenticationLogs remain empty while EasyAuth is generating 403 responses?
4. Is there a customer-accessible way to enable detailed EasyAuth token-validation diagnostics on Linux App Service, including audience, issuer, signature, expiry, tenant, and azp/appid validation results?
5. Could this behavior be caused by an EasyAuth token-validation cache or worker-local authentication state?
6. Would forcing MSAL to acquire a fresh API access token with forceRefresh: true and retrying the request once be an appropriate mitigation?
7. How can we distinguish a stale or invalid client token from an EasyAuth platform-side issue without logging the raw access token?
8. If these details are only available in internal App Service traces, what is the correct support channel for an Azure subscription whose technical-support workflow redirects to Microsoft Q&A?

We can provide exact UTC incident windows, resource IDs, hostnames, and affected-user identifiers privately to Microsoft support, but have omitted them here because this is a public forum.We are investigating recurring HTTP 403 responses generated by Azure App Service built-in authentication (EasyAuth).

The issue has occurred on both the production app and its staging deployment slot. It affects one user at a time, persists for approximately 30 minutes, and then resolves automatically without a deployment, restart, or configuration change. Other users can continue using the service normally.

Architecture

• Frontend: React SPA using @azure/msal-browser
• Backend: Linux Azure App Service running Node.js/Express
• Authentication: App Service built-in authentication with Microsoft Entra ID
• The SPA obtains an access token for the backend API and sends it in the Authorization: Bearer header
• Production and staging use the same frontend client application but separate App Service endpoints

Observed behavior

For an affected request:

1. The browser sends a CORS OPTIONS request, which returns HTTP 200.
2. The subsequent authenticated GET request returns HTTP 403.
3. App Service HTTP logs classify it as CallerError.
4. The 403 response completes in approximately 2–14 ms.
5. The response body is empty.
6. There is no corresponding request in the backend Application Insights requests table.

This indicates that the request is rejected by EasyAuth before reaching the Node.js/Express application.

The affected endpoints are ordinary authenticated read endpoints, including:

• GET /api/v2/me
• GET /api/v2/view-management/profile
• GET /api/v2/announcements

During one staging incident, the failures persisted for approximately 32 minutes:

• /api/v2/me: 52 responses with HTTP 403
• /api/v2/view-management/profile: 14 responses with HTTP 403
• /api/v2/announcements: 50 responses with HTTP 403

A production incident showed the same pattern for approximately 31 minutes.

All observed failed requests were handled by the same App Service worker. This does not appear to be an IP access-restriction issue:

• App Service access restrictions allow all traffic.
• The CORS preflight succeeds.
• Other users continue to receive successful responses.
• The affected user eventually recovers without any server-side action.

Logs checked

We enabled the applicable App Service diagnostic categories and sent them to Log Analytics.

AppServiceHTTPLogs contains the platform-generated 403 responses, but does not include:

• EasyAuth rejection reason
• Token audience or authorized-party validation result
• Token hash
• User identity
• Authentication correlation ID

AppServiceAuthenticationLogs contains zero records for the incident windows. The authentication-log category is also not supported for the staging slot in our environment.

Backend Application Insights contains no matching 403 requests, confirming that the requests did not enter Express.

The frontend Application Insights shows successful calls to the Microsoft Entra token endpoint during the broader incident windows. However, the telemetry does not show which resource or scope each token request targeted, so it does not prove that a fresh backend API token was obtained.

Questions

1. What EasyAuth condition can cause one user’s authenticated GET requests to return 403 continuously for approximately 30 minutes and then recover automatically?
2. Is an empty, platform-generated 403 with Result=CallerError associated with a documented EasyAuth validation failure?
3. Why might AppServiceAuthenticationLogs remain empty while EasyAuth is generating 403 responses?
4. Is there a customer-accessible way to enable detailed EasyAuth token-validation diagnostics on Linux App Service, including audience, issuer, signature, expiry, tenant, and azp/appid validation results?
5. Could this behavior be caused by an EasyAuth token-validation cache or worker-local authentication state?
6. Would forcing MSAL to acquire a fresh API access token with forceRefresh: true and retrying the request once be an appropriate mitigation?
7. How can we distinguish a stale or invalid client token from an EasyAuth platform-side issue without logging the raw access token?
8. If these details are only available in internal App Service traces, what is the correct support channel for an Azure subscription whose technical-support workflow redirects to Microsoft Q&A?

We can provide exact UTC incident windows, resource IDs, hostnames, and affected-user identifiers privately to Microsoft support, but have omitted them here because this is a public forum.