Problem with Azure API Authentication

Question

Hi there

I created the following in Azure.

A Web App which is an API to be used by a MAUI application

An Enterprise Application for the Web App

A service principal for the web app.

When I use the MAUI application, the login is fine and the authentication works perfectly. The problem I am facing is that I need to connect to the api from an Excel workbook and for that I need to acquire a token and pass that through. In postman I am using https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/token to get a token. I pass in the client id, secret and scope and get back a token. I have used two different scopes. {clientId}/.default and https://management.azure.com/.default

For both I get back an access token, but neither works when I try and access the api. Could you please tell me what I am doing wrong. The api simply has [Authorize] decorated over the api methods, so it should just be making sure that it has a valid token. But I can't get it to return a simple get request.

Answer 1

It turns out that the authentication needs a username and password, it can't accept client credential flow. I got it sorted. thanks

Answer 2

Hello @Jai Holloway

Thank you for confirming that your issue is resolved. Yes in some scenarios, it may not take client secret rather requires username and password. Please feel free to reach out to us in case of any further queries.

Answer 3

The API isn’t accepting the tokens because the access token you’re acquiring isn’t issued for your API. It’s being issued for other resources (management.azure.com or the client app itself), so the aud (audience) claim doesn’t match what the API expects.

For an ASP.NET / ASP.NET Core API protected with [Authorize] and Microsoft Entra ID, the token must:

1. Be issued for the correct resource / scope (your API).
2. Be requested with the correct grant type and permissions type (delegated vs application) that match how the API is configured.

Use the following checks and steps:

1. Confirm the API’s Application ID URI / scope
   • In Microsoft Entra admin center → App registrations → select the API app registration.
   • Under Expose an API, note the Application ID URI (for example api://{api-app-client-id} or a custom URI).
   • Also note any defined scopes, for example api://{api-app-client-id}/Forecast.Read.
2. Request a token for the API, not for management.azure.com
   • In the token request (Postman or code), the scope must be either:
     • api://{application_client_id}/SomeScope (a specific delegated scope), or
     • api://{application_client_id}/.default (for application permissions / client credentials against that API),
   • Do not use https://management.azure.com/.default unless calling Azure Resource Manager.
   • Do not use {clientId}/.default where {clientId} is the client app; it must be the API’s Application ID URI.
   The pattern is illustrated in the Insomnia example:
   • SCOPE: api://{application_client_id}/Forecast.Read
   where {application_client_id} is the web API registration, not the client.
3. Match flow type to API configuration
   • If the API is meant to be called on behalf of a user (like from MAUI), it should expose delegated permissions (scopes). The client then uses an interactive/user flow and requests those scopes.
   • If calling from Excel/VBA or a background process using client credentials (client id + secret), the API must expose application permissions and be configured to accept app-only tokens.
   • If the API only exposes application permissions and you try to use a delegated flow with /.default, you can hit issues like described in the AADSTS50000 scenario; the fix is to expose delegated permissions when using delegated flows.
4. Acquire the token correctly
   • For a daemon / service principal (client credentials) calling a web API:
     • POST https://login.microsoftonline.com/{tenantID}/oauth2/v2.0/token
     • Body (form-data or x-www-form-urlencoded):
       • grant_type=client_credentials
       • client_id={client-id-of-calling-app}
       • client_secret={secret-of-calling-app}
       • scope={Application-ID-URI-of-API}/.default (for example api://contoso.azurewebsites.net/aaaabbbb-0000-cccc-1111-dddd2222eeee/.default)
   • This pattern is shown in the custom extension troubleshooting article where a client credentials token is acquired for a custom API.
5. Verify the token audience (aud)
   • After acquiring the token, paste it into https://jwt.ms as shown in the custom extension article.
   • Confirm:
     • aud equals the API’s client ID (or Application ID URI, depending on configuration).
     • iss matches the tenant.
   • If aud is https://management.azure.com/ or something other than your API, the API will reject it.
6. If using delegated flow from MAUI vs Excel
   • MAUI likely uses MSAL and AcquireTokenSilent / interactive login with the correct scopes for the API, as described in the “web app that calls web APIs” scenario.
   • Excel/VBA or Postman must request the same scopes for the same resource (the API) to get a token that the API will accept.
7. If you see AADSTS50000 with /.default
   • If using an OAuth 2 delegated grant flow with /.default and the resource app exposes only application permissions, you must:
     • Configure the resource application (your API) to expose delegated permissions, and
     • Consent to those delegated permissions in the client application.

Once the token is requested for the correct Application ID URI and scopes, and the API is configured to accept that type of token (delegated or application), the [Authorize] attribute will accept the token and the GET request should succeed.

---

References:

• A web app that calls web APIs: Acquire a token for the app
• Acquire tokens to call a web API using a daemon application
• Error AADSTS50000 getting a token or signing in to an Azure app
• Authentication
• Authorization and the Microsoft Graph Security API
• Call an ASP.NET Core web API with Insomnia (no-api)
• Troubleshoot your custom authentication extension