Azure App Service Linux Easy Auth returns HTTP 500 on Microsoft Entra OAuth callback

Enable AppServiceAuthenticationLogs, reproduce one sign-in, and correlate the callback’s CorrelationId, because on Linux the /.auth/login/aad/callback endpoint is processed by the isolated Easy Auth container before any application code runs.^1^

Capture the Easy Auth failure

1. In the App Service, open Monitoring → Diagnostic settings.
2. Create or edit a diagnostic setting that sends the App Service authentication log category to a Log Analytics workspace. If the authentication category is not offered for this resource, record that fact for the support case.
3. Reproduce one login through an ingress path permitted by the current network restrictions. Record:
   • Exact UTC time
   • Hostname used
   • Callback HTTP status
   • Any request/correlation identifiers in the response headers
4. Open the destination workspace → Logs, then run:

AppServiceAuthenticationLogs
| where TimeGenerated > ago(30m)
| where StatusCode >= 400
    or Level in~ ("Error", "Warning")
| project TimeGenerated, CorrelationId, OperationName,
          TaskName, StatusCode, SubStatusCode,
          Message, Details, HostName, ModuleRuntimeVersion
| order by TimeGenerated asc

The table is generated specifically by App Service Authentication and includes CorrelationId, error details, HTTP/substatus codes, and the authentication middleware runtime version.^2^

After identifying the failed callback, isolate its complete sequence:

let failedId = "<correlation-id>";
AppServiceAuthenticationLogs
| where TimeGenerated > ago(2h)
| where CorrelationId == failedId
| project TimeGenerated, Level, OperationName, TaskName,
          StatusCode, SubStatusCode, Message, Details,
          HostName, ModuleRuntimeVersion
| order by TimeGenerated asc

Ordinary container output may show no exception because Linux Easy Auth runs in a separate container. The middleware validates and stores tokens, establishes the session, and only then creates the authentication cookie.^1^

Inspect the effective configuration

Since the Entra-side checks, secret rotation, restart, and browser isolation have already been completed, inspect what the middleware actually received rather than repeating those checks:

az rest --method GET \
  --url '/subscriptions/[Subscription ID] ID]/resourceGroups/[Resource Group] Group]/providers/Microsoft.Web/sites/{APP_NAME}/config/authsettingsv2/list?api-version=2020-06-01' \
  > authsettingsv2.json

This is the documented method for retrieving the effective authsettingsV2 resource.^3^

Review—without posting secret values publicly—the following fields:

• platform.enabled
• globalValidation.requireAuthentication
• globalValidation.redirectToProvider
• identityProviders.azureActiveDirectory.enabled
• identityProviders.azureActiveDirectory.registration.clientId
• identityProviders.azureActiveDirectory.registration.openIdIssuer
• identityProviders.azureActiveDirectory.registration.clientSecretSettingName
• identityProviders.azureActiveDirectory.validation.allowedAudiences
• login.tokenStore.enabled

For a workforce single-tenant registration, the current documented issuer form is the tenant-specific Microsoft identity platform v2 issuer. The client secret should be referenced through an application-setting name; App Service’s standard automatically created setting is MICROSOFT_PROVIDER_AUTHENTICATION_SECRET.^4^

Check whether the portal shows an Upgrade button under Settings → Authentication. Only if it does, the app is using the V1 management model. V2 is required by the current portal experience, and migration moves provider secrets into slot-sticky application settings.^5^ Do not manually migrate merely as a diagnostic step; Microsoft documents that manual/version migration has management implications and may not be reversible.

Run platform diagnostics and escalate

Open App Service → Diagnose and solve problems and search for Authentication and authorization or App Service Authentication (built-in). Also review Application Changes around the failure time. App Service Diagnostics supports Linux apps and is most useful for events in the previous 24 hours.^6^

If the authentication table remains empty or only reports a generic internal error, open an Azure support request under Azure App Service → Azure App Service built-in authentication and include:

• Failed callback UTC timestamps and hostname
• CorrelationId, status, and substatus
• ModuleRuntimeVersion
• Sanitized authsettingsV2 output
• App Service resource ID, region, Linux runtime, and instance count
• Confirmation that no application is deployed and no request reaches application code
• Diagnostic dump from Development Tools → Advanced Tools → Go → Tools → Diagnostic dump; on Linux it contains host and container console output.^7^

This evidence can distinguish token-exchange/configuration rejection from an instance-specific middleware failure. The callback location and absent application deployment make a platform-authentication failure plausible, but Microsoft does not document this symptom as one universal Linux Easy Auth known issue; the authentication log details or platform telemetry are needed to establish that conclusion.

References

1. Authentication and Authorization - Azure App Service
2. Azure Monitor Logs reference - AppServiceAuthenticationLogs - Azure ...
3. Tutorial: Access Microsoft Graph from a secured JavaScript app as the user
4. Configure Microsoft Entra Authentication - Azure App Service
5. Manage the API and runtime versions of App Service authentication
6. Troubleshoot with Diagnostics - Azure App Service
7. Enable Diagnostic Logs - Azure App Service | Microsoft Learn