A developer copies the access token from a working Microsoft Graph call and uses it as the bearer token for a Dataverse Web API request to https://northwind.crm.dynamics.com. The Graph call succeeds, but Dataverse rejects the request as unauthorized. The user has a valid Dataverse security role. What is the cause?
Select an answer to reveal the explanation.
Short Explanation
A token is like a concert wristband: it's real, but it only gets you into the venue it was printed for. Graph tokens say 'Graph' in their audience, so Dataverse won't accept them. Ask Entra ID for a separate token scoped to your Dataverse environment.
Full Explanation
Every access token issued by Microsoft Entra ID names one resource in its audience claim, and resource servers validate that claim before doing anything else. A token acquired for Microsoft Graph has Graph as its audience, so the Dataverse Web API rejects it even though the signature, issuer, and user are all legitimate. The client must acquire a second token, using MSAL's silent acquisition with the cached account, for a scope that starts with the Dataverse environment URL. Token expiry is not the issue: the Graph call just succeeded with the same token, and Dataverse does not impose a shorter lifetime than other resources on Entra ID tokens. OData-MaxVersion and OData-Version headers control protocol negotiation for the response format; omitting them does not cause token rejection, and they have no role in authentication. A Microsoft 365 license is irrelevant to token validation; Dataverse access depends on the user being enabled in the environment with a security role, which the scenario already confirms. Exam caveat: one MSAL account can hold tokens for several resources at once, but each API call needs the token minted for that API. Operational check: decode the failing token and compare its aud claim with the environment URL; a Graph audience confirms the diagnosis immediately.