# AADSTS901002 fix: resource parameter sent to v2.0 endpoint

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

**Short answer:** AADSTS901002 means an app sent the v1.0 `resource` parameter to the Microsoft identity platform (v2.0) endpoint, which only takes `scope`. It is a configuration mismatch, often in third-party products set up with v2.0 URLs. Low attack value. Replace `resource=<API>` with `scope=<API>/.default`, or point the app at the v1.0 endpoints it was built for.

**Fix:** Developer: replace `resource=<API URI>` with `scope=<API URI>/.default` in requests to `/oauth2/v2.0/`. Admin of a third-party product: if the product only supports v1.0, use the v1.0 endpoint URLs, without `v2.0` in the path. User: report it to IT.

| Field | Value |
|---|---|
| Code | AADSTS901002 |
| Category | App configuration |
| 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 AADSTS901002 mean?

Microsoft's description:

> AADSTS901002: The 'resource' request parameter isn't supported.

The app talks to the Microsoft identity platform endpoint (URLs containing `/oauth2/v2.0/`) but builds its request the v1.0 way, with a `resource` parameter.

The two endpoints name the target API differently. Microsoft's v1.0-to-v2.0 comparison shows a v1.0 request with `&resource=https://graph.microsoft.com/` and the v2.0 equivalent with `&scope=https://graph.microsoft.com/directory.read%20...`. On v2.0, *"the **scope** parameter indicates which resource and permissions the app is requesting authorization. The desired resource is still present in the request - it's encompassed in each of the values of the scope parameter."*

There is a direct translation. Microsoft's scopes reference: *"Using `scope={resource-identifier}/.default` is functionally the same as `resource={resource-identifier}` on the v1.0 endpoint."* Neither the authorization code flow nor the client credentials flow reference lists a `resource` parameter for v2.0.

Not the same as [500011](https://brambrinkmeier.com/entra/aadsts/500011/). 500011 means the API you named doesn't exist in the tenant. 901002 means you named it with a parameter the endpoint doesn't accept.

## Is it an attack?

No. It is a configuration mismatch between an app and the endpoint it was pointed at. The request fails and no token is issued.

| Pattern | Likely meaning |
|---|---|
| A third-party product (BI tool, CMS plug-in, SSO module) right after it was set up | The admin entered v2.0 endpoint URLs into a product that sends `resource`. IBM documents the error for Cognos Analytics, which logs *"Call to IdP failed to get identity. Status 400"* and `invalid_request`. |
| A home-built app after someone "upgraded" its URLs to v2.0 | The URLs changed but the request parameters didn't. |
| A script that mixes v1.0 examples with a v2.0 token URL | Same mismatch, by hand. |

Exclude it from failure-based attack detections.

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

Microsoft doesn't document whether or where 901002 is logged. The request is invalid, so a sign-in row may not exist. Check all three tables:

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

Which apps send the v1.0 parameter, and since when:

```kusto
union SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(14d)
| where ResultType == "901002"
| summarize Rows = count(), Users = dcount(UserPrincipalName),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            IPs = make_set(IPAddress, 5)
          by AppDisplayName, AppId, ServicePrincipalName
| sort by Rows desc
```

`AppDisplayName` is empty for rows from `AADServicePrincipalSignInLogs`, which uses `ServicePrincipalName`. `ResultType` is a **string** column, so compare it with `"901002"`, not `901002`. A `FirstSeen` that matches the day a product was configured confirms the cause.

## How do I fix AADSTS901002?

**For the user:** you can't fix this yourself. Report it to IT, with the name of the app.

**For developers:**
1. Remove `resource` from requests to `/oauth2/v2.0/authorize` and `/oauth2/v2.0/token`.
2. Put the API in `scope` instead. For the same access as `resource=https://graph.microsoft.com`, send `scope=https://graph.microsoft.com/.default`. For specific delegated permissions, append them to the API identifier, as in Microsoft's example `https://graph.microsoft.com/Calendars.Read`.
3. For the client credentials flow, `scope` is required and must be *"the resource identifier (application ID URI) of the resource you want, suffixed with `.default`"*.

**For admins of a third-party product:**
1. Check which endpoint the product expects. If its documentation asks for a "resource" or "resource URI", it is built for v1.0.
2. Then configure the v1.0 URLs, without `v2.0` in the path. Microsoft's comparison page shows the v1.0 authorize request as `https://login.microsoftonline.com/common/oauth2/authorize`. It doesn't show the token URL; our reading is that it is `.../oauth2/token` on the same pattern.
3. If the product supports v2.0, switch its setting from resource to scope instead. Follow the vendor's guide; IBM's Cognos article is behind a login, so we couldn't read its exact steps.

## 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. [Why update to Microsoft identity platform (v2.0)?](https://learn.microsoft.com/en-us/previous-versions/azure/active-directory/azuread-dev/azure-ad-endpoint-comparison)
3. [Scopes and permissions in the Microsoft identity platform](https://learn.microsoft.com/entra/identity-platform/scopes-oidc)
4. [Microsoft identity platform and the OAuth 2.0 client credentials flow](https://learn.microsoft.com/entra/identity-platform/v2-oauth2-client-creds-grant-flow)
5. [Microsoft identity platform and OAuth 2.0 authorization code flow](https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow)
6. [SigninLogs table reference (Azure Monitor)](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs)
7. [Configure Cognos Analytics with Azure AD shows AADSTS901002 (IBM Support)](https://www.ibm.com/support/pages/configure-cognos-analytics-azure-ad-show-error-message-aadsts901002-resource-request-parameter-not-supported)

## Related codes

[AADSTS500011](https://brambrinkmeier.com/entra/aadsts/500011/), [AADSTS900144](https://brambrinkmeier.com/entra/aadsts/900144/), [AADSTS9002313](https://brambrinkmeier.com/entra/aadsts/9002313/), [AADSTS90014](https://brambrinkmeier.com/entra/aadsts/90014/)

## 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, "AADSTS901002 fix: resource parameter sent to v2.0 endpoint", https://brambrinkmeier.com/entra/aadsts/901002/ (CC BY 4.0), last updated 2026-11-01.