Issue with authenticated App Service

Question

Issue with authenticated App Service

Paul Harris 0

I have created an ASP API app written in C#. The app is expecting Access Tokens issued by an Entra directory.
When I test on my laptop, I get an access token, then use it call the locally hosted API and it all works fine.

When I deploy the API to azure it breaks! Any call to the API now gets 'Internal Server Error'.

I am new to Azure app service hosting and I am stuck! Any ideas?

Praneeth Maddali 10,460 Reputation points Microsoft External Staff Moderator

2026-06-19T08:24:35.1466667+00:00

Hi @Paul Harris Thank you for contacting us about the Issue with authenticated App Service. We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this
Praneeth Maddali 10,460 Reputation points Microsoft External Staff Moderator

2026-06-19T09:01:28.4533333+00:00
Hi @Paul Harris

This is a really common first-deployment hurdle, and it's usually quick to sort out. The important thing to know is that a 500 Internal Server Error here is generic: App Service is just telling you the app threw an unhandled exception while hiding the real reason by default. So let's surface the actual error first, then fix the most likely cause.

Step 1 : See the real error (do this first) In the portal: App Service > Monitoring > App Service logs > turn Application Logging (Filesystem) to On and Detailed error messages to On. Open Log stream (just below) and call your API again — the real stack trace should appear.

For startup-level errors, you can also enable stdout logging via Advanced Tools (Kudu) > Debug console > site/wwwroot > edit web.config and set stdoutLogEnabled="true".

Most likely cause Your Entra ID settings (TenantId, ClientId, etc.) are probably coming from appsettings.Development.json or User Secrets locally. These don’t get deployed, and Azure runs in the Production environment, so the values are missing at runtime → JWT middleware fails to initialize > 500 error.

Fix: Add the values under App Service > Settings > Configuration > Application settings. Use double-underscore notation for nested sections.

If you're using Microsoft.Identity.Web (recommended), add these:

AzureAd__Instance > https://login.microsoftonline.com/

AzureAd__TenantId > your tenant ID

AzureAd__ClientId >your API's Client ID

AzureAd__Audience > api://your-client-id (or your App ID URI from "Expose an API")

These will override your appsettings.json at runtime.

After adding these, redeploy and test with the same token that worked locally. If you start seeing 401s instead, decode the token at jwt.ms and verify the aud and iss claims match your configuration.

Let me know what the Log stream shows (and whether you’re using Microsoft.Identity.Web or raw JwtBearer), and I’ll help pinpoint the exact next step.

Reference:

https://learn.microsoft.com/en-us/aspnet/core/test/troubleshoot-azure-iis?view=aspnetcore-10.0

https://learn.microsoft.com/en-us/azure/app-service/configure-common?tabs=portal

https://learn.microsoft.com/en-us/entra/identity-platform/scenario-protected-web-api-app-configuration?tabs=aspnetcore

https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/app-integration/401-unauthorized-aspnet-core-web-api

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.

1 answer

Your answer

Praneeth Maddali 10,460 Reputation points Microsoft External Staff Moderator

2026-06-19T08:24:35.1466667+00:00

Hi @Paul Harris Thank you for contacting us about the Issue with authenticated App Service. We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this

Answer 1

The most common cause for an API that works locally but fails with 500 Internal Server Error after deployment to Azure App Service, when using Microsoft Entra ID access tokens, is a mismatch between how tokens are validated in Azure and how the app is configured (audience, issuer, or missing headers/middleware). Another frequent cause is misconfiguration when running behind a gateway/proxy.

Use the following checks and fixes:

Check that the API receives a valid Bearer token in Azure
- Ensure the client calls the Azure-hosted API with an Authorization: Bearer <token> header.
- If the request has no token or an invalid token, the API can return 401 or 500 depending on error handling.
Verify audience (aud) matches what the API expects
- Decode the JWT at https://jwt.ms.
- Check the aud claim.
- Ensure it matches the API’s configured audience (for example, api://<application-client-id> or the App ID URI configured for the API).
- If the token is issued for a different resource, token validation fails and can surface as 401/500.
Align API token validation with Entra configuration
- In the API’s TokenValidationParameters, ensure ValidAudience/ValidAudiences and ValidIssuer/ValidIssuers match the values from the Entra app registration:
  - aud must match the API’s App ID URI or client ID.
  - iss must match the tenant’s issuer (for example, https://login.microsoftonline.com/<tenant-id>/v2.0).
- If the API is behind a gateway or uses multiple URLs, add all valid audiences as shown in the gateway troubleshooting guidance.
If the API is behind a gateway or proxy, configure forwarded headers
- When deployed behind a gateway (Front Door, Application Gateway, API Management, etc.), missing forwarded headers can cause redirect or token validation issues.
- Ensure the middleware order includes forwarded headers before authentication:
```
     app.UseForwardedHeaders();
     app.UseAuthentication();
     app.UseAuthorization();
```
- Verify the gateway forwards X-Forwarded-Proto and X-Forwarded-Host.
Troubleshoot 401/500 by enabling detailed logging
- Use JwtBearerEvents or Serilog-based logging to capture token validation errors and see why the API is failing in Azure.
- Enable debug logging for Microsoft.Identity and Microsoft.IdentityModel to see detailed token validation messages.
Check for generic 401/500 causes
- A 401/500 can also occur if:
  - The token is expired.
  - The token is missing required claims.
  - The token’s issuer or audience does not match the API configuration.
- Use the logging guidance to confirm which of these applies.
If using a gateway, validate the audience and headers again
- For APIs behind gateways, explicitly check:
  - The aud claim matches one of the configured valid audiences (e.g., api://your-client-id, backend URL, or gateway URL as configured).
  - Forwarded headers are correctly handled and UseForwardedHeaders is configured before authentication.

Applying these checks will typically reveal whether the issue is an audience/issuer mismatch, missing/misrouted headers, or a misconfigured authentication pipeline in Azure App Service.

References:

Share via

Issue with authenticated App Service

1 answer

Your answer