AADSTS65002 fix: Microsoft app not preauthorized for API

What does AADSTS65002 mean?

Microsoft’s description:

Consent between first party application ‘{applicationId}’ and first party resource ‘{resourceId}’ must be configured via preauthorization - applications owned and operated by Microsoft must get approval from the API owner before requesting tokens for that API. A developer in your tenant might be attempting to reuse an App ID owned by Microsoft. This error prevents them from impersonating a Microsoft application to call other APIs. They must move to another app ID they register.

Both sides of the request are Microsoft apps (“first party”). The client app isn’t on the API’s preauthorized list, so Entra ID refuses the token. The error names both app IDs, so you can see exactly which pair failed.

The difference from 65001: with 65001 a user or admin in your tenant can grant the missing consent. With 65002 nobody in your tenant can. Microsoft’s text says the approval comes from “the API owner”, which is Microsoft. A Microsoft moderator’s accepted answer in a Q&A thread about Azure Virtual Desktop single sign-on puts it similarly: “This type of consent is not intended to be granted manually by end users or tenant admins and must be handled via internal preauthorization within Microsoft’s platform.”

Is it an attack?

Usually not. Users report three situations:

Pattern	Likely meaning
Client 04f0c124-f2bc-4f59-8241-bf6df9866bbd, from a developer machine	Visual Studio sign-in through the Azure SDK (VisualStudioCredential). Microsoft’s Azure SDK troubleshooting guide lists this exact error and says the Visual Studio client “is not yet pre-authorized for the Azure resource mentioned in the error.”
A script or integration that sends a Microsoft-owned client ID	A developer copied a Microsoft client ID into their own code. This is the case Microsoft’s description warns about. The row rests on Microsoft’s description. One Q&A thread is sometimes read as this case, but the poster was using their own client ID and the thread was never resolved, so it doesn’t show it.
Client 9cdead84-a844-4324-93f2-b2e6bb768d07 (Azure Virtual Desktop) for resource 00000002-0000-0000-c000-000000000000	An Azure Virtual Desktop user on an old web client URL. The app names come from the poster’s Enterprise applications list. The poster fixed it by switching to the current web client.
One user or IP hitting 65002 for several different Microsoft client IDs in a short time	Our interpretation, not documented: someone is trying Microsoft client IDs one after another to find one that gets a token. Microsoft’s text calls 65002 a guard against “impersonating a Microsoft application”. Check who and where.

The error itself gives nothing away: no token is issued.

How do I find it in my logs (KQL)?

Microsoft doesn’t document which sign-in table 65002 lands in. Check all three:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "65002"
| summarize Rows = count(), Clients = dcount(AppId) by SourceTable

Which client and resource pairs fail, and from what. Microsoft’s page on verifying first-party apps gives two Microsoft owner tenants: f8cdef31-a31e-4b4a-93e4-5f571e91255a (“the Microsoft Service’s Microsoft Entra tenant ID”) and 72f988bf-86f1-41af-91ab-2d7cd011db47, under which its table lists Microsoft-owned apps. The IsMicrosoftClient column checks both:

union SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "65002"
| extend IsMicrosoftClient = AppOwnerTenantId in ("f8cdef31-a31e-4b4a-93e4-5f571e91255a", "72f988bf-86f1-41af-91ab-2d7cd011db47")
| summarize Rows = count(), Users = dcount(UserPrincipalName),
            UserAgents = make_set(UserAgent, 5), IPs = make_set(IPAddress, 5)
          by AppDisplayName, AppId, IsMicrosoftClient, ResourceDisplayName, ResourceIdentity
| sort by Rows desc

One user or IP trying several different client IDs and getting 65002. A threshold of 3 client IDs in an hour is a starting point; raise it if your developers trigger it:

union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(1d)
| where ResultType == "65002"
| summarize ClientIds = dcount(AppId), Clients = make_set(AppDisplayName, 10),
            Resources = make_set(ResourceDisplayName, 10)
          by UserPrincipalName, IPAddress, bin(TimeGenerated, 1h)
| where ClientIds >= 3
| sort by ClientIds desc

ResultType is a string column, so compare it with "65002", not 65002. If an app in the results is unfamiliar, Microsoft’s guide to verifying first-party apps shows how to check its owner: in Enterprise applications, filter Application Type to Microsoft Applications. First-party apps don’t always have a service principal in your tenant, so they can appear in sign-in logs without appearing there.

How do I fix AADSTS65002?

For the user: you can’t fix this with consent, and neither can your admin. Report the error with both app IDs to whoever runs the app. On Azure Virtual Desktop, a user fixed it by using https://client.wvd.microsoft.com/arm/webclient instead of the old https://rdweb.wvd.microsoft.com/ address.

For developers:

1. Look at the client ID your code actually sends. If it belongs to Microsoft, Microsoft’s instruction is plain: “They must move to another app ID they register.”
2. Register your own app, add the API permissions it needs under API permissions, and get them consented. Then send that client ID.
3. Azure SDK with VisualStudioCredential: the Azure SDK guide points to Visual Studio’s pre-authorization guidance. The reporter in the GitHub issue said that didn’t help for Azure Monitor Control Service. Our reading: switch to a different credential, or your own app registration, for that resource.

For admins:

1. Use the second query to find the client, the resource and the user agent. That tells you whether it is a developer tool, a script or an end-user client.
2. Don’t look for a consent button. There isn’t one for this error.
3. If the third query returns hits from an unfamiliar IP, treat it like any other suspicious sign-in for that user.