# AADSTS65002 fix: Microsoft app not preauthorized for API

Canonical: https://brambrinkmeier.com/entra/aadsts/65002/
By Bram Brinkmeier. JSON: https://brambrinkmeier.com/api/aadsts/65002.json

**Short answer:** AADSTS65002 means a Microsoft-owned client app asked for a token for a Microsoft-owned API it isn't preauthorized for. Nobody in your tenant can grant that consent. Users hit it from Visual Studio sign-in in the Azure SDK, from scripts that borrow a Microsoft client ID, and from an old Azure Virtual Desktop web client URL. Use your own app registration or the current client.

**Fix:** Developer: stop using a Microsoft-owned client ID. Register your own app, add the API permissions it needs, and use that client ID. Azure SDK with Visual Studio sign-in: use another credential or your own app. Azure Virtual Desktop user: open the current web client, not the old rdweb URL.

| Field | Value |
|---|---|
| Code | AADSTS65002 |
| Category | Consent and app permissions |
| Type | Configuration error |
| Attack signal | Low: usually configuration or user error |
| In Microsoft's error reference | Yes |
| Verification | documentation |
| Last updated | 2026-11-01 |

## 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](https://brambrinkmeier.com/entra/aadsts/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 `{guid}`, 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:

```kusto
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:

```kusto
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:

```kusto
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.

## Evidence

Not reproduced in the lab yet; the page is based on Microsoft's documentation.

## Sources

1. [Microsoft Entra authentication and authorization error codes](https://learn.microsoft.com/entra/identity-platform/reference-error-codes)
2. [Verify first-party Microsoft applications in sign-in reports](https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/governance/verify-first-party-apps-sign-in)
3. [SigninLogs table reference (Azure Monitor)](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs)
4. [Azure Identity client library for .NET troubleshooting guide (Microsoft, GitHub)](https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/identity/Azure.Identity/TROUBLESHOOTING.md)
5. [VisualStudioCredential error AADSTS65002 connecting to Azure Monitor Control Service (GitHub issue)](https://github.com/Azure/azure-sdk-for-net/issues/44107)
6. [401 / AADSTS65002 when trying to authenticate with api.partner.microsoft.com (Microsoft Q&A)](https://learn.microsoft.com/en-us/answers/questions/962674/401-aadsts65002-when-trying-to-authenticate-with-a)
7. [AVD setup configured with SSO errors at the consent (Microsoft Q&A)](https://learn.microsoft.com/en-us/answers/questions/2282577/avd-setup-configured-with-sso-errors-at-the-consen)

## Related codes

[AADSTS65001](https://brambrinkmeier.com/entra/aadsts/65001/), [AADSTS90094](https://brambrinkmeier.com/entra/aadsts/90094/), [AADSTS500011](https://brambrinkmeier.com/entra/aadsts/500011/), [AADSTS700016](https://brambrinkmeier.com/entra/aadsts/700016/)

## License and citation

CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). CC BY 4.0 covers the author's own text and classification fields. Quoted Microsoft error wording belongs to Microsoft, is quoted with its source and can change.

Cite as: Bram Brinkmeier, "AADSTS65002 fix: Microsoft app not preauthorized for API", https://brambrinkmeier.com/entra/aadsts/65002/ (CC BY 4.0), last updated 2026-11-01.