We've been migrating our internal line-of-business applications from the Azure AD Graph (v1.0) endpoints to the Microsoft Graph (v2.0) endpoints, following the deprecation timeline. Post-migration, a significant subset of our services are now failing with `invalid audience` errors during token validation.
Our architecture is typical for .NET services:
* ASP.NET Core applications using `Microsoft.Identity.Web` for token acquisition and validation.
* Tokens are acquired for ` https://graph.microsoft.com` (the resource) using client credentials flow.
* The `aud` claim in the returned access token is correctly ` https://graph.microsoft.com`.
* Our validation logic, configured via `AddMicrosoftIdentityWebApi`, is rejecting these tokens.
Our initial validation configuration in `Startup.cs` was:
```csharp
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApi(Configuration, "AzureAd");
```
With `appsettings.json`:
```json
"AzureAd": {
"Instance": "https://login.microsoftonline.com/",
"TenantId": "[our-tenant-id]",
"ClientId": "[our-client-id]",
"Audience": "https://graph.microsoft.com"
}
```
The error manifests as:
```
IDX10214: Audience validation failed. Audiences: '[ https://graph.microsoft.com ]'. Did not match: validationParameters.ValidAudience: '[api://our-client-id]' or validationParameters.ValidAudiences: 'null'.
```
It appears the library is ignoring the configured `Audience` and defaulting to the `ClientId` (forming it as `api://{ClientId}`). This was not an issue with v1.0 tokens.
What we've tried:
* Explicitly setting `TokenValidationParameters.ValidAudience` in the JWT bearer options.
* Using the `Authority` setting instead of `Instance` + `TenantId`.
* Verified the App Registration's `api://{ClientId}` identifier URI is present (though we don't use it).
Has anyone successfully navigated this specific configuration pivot? The core question is: **when acquiring a token for Microsoft Graph from a daemon/service app, what should the `Audience` field in the validation configuration be, and why is the library seemingly defaulting to the `api://{ClientId}` format despite our explicit setting?** We're looking for the precise combination of App Registration manifest settings (if any) and the corresponding validation code.
Instrument everything.
You're likely hitting the v2.0 endpoint's stricter default multi-tenant behavior. The `Audience` property in your config is the *expected* audience for tokens sent *to your API*. It's not for validating tokens you *acquire* to call Microsoft Graph.
When you get a token for ` https://graph.microsoft.com` and then present it to your own service, your service sees the `aud` claim is for Graph, not for your own API's client ID or application ID URI. That's the mismatch.
You need to configure your service's token validation to accept tokens issued to Graph as valid for your service, since you're forwarding them. In `AddMicrosoftIdentityWebApi`, set the `ValidAudiences` or use the `TokenValidationParameters` directly. Something like:
```csharp
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApi(options =>
{
options.TokenValidationParameters.ValidAudiences = new List
{
Configuration["AzureAd:ClientId"], // your API
"https://graph.microsoft.com" // the graph token you're passing through
};
}, Configuration, "AzureAd");
```
The v1.0 endpoint was often more permissive about this.
patch early