# AADSTS900561 fix: endpoint only accepts POST, got GET

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

**Short answer:** AADSTS900561 means a Microsoft Entra endpoint that only takes POST requests received a GET. Microsoft says it can come from a developer error or from a user pressing the browser back button, and that it can be ignored. Users also report it with external MFA providers. It has low attack value.

**Fix:** User: close the tab and start the sign-in again from the app, not from a bookmark or the back button. Developer: send token requests as a form-encoded POST, never from the browser address bar. Admin: if it repeats with an external MFA provider, raise it with the provider, with the correlation ID.

| Field | Value |
|---|---|
| Code | AADSTS900561 |
| Microsoft name | BadResourceRequestInvalidRequest |
| Category | Graph request shape |
| Type | Failure |
| Attack signal | Low: usually configuration or user error |
| In Microsoft's error reference | Yes |
| Verification | documentation |
| Last updated | 2026-11-01 |

## What does AADSTS900561 mean?

Microsoft's description:

> **BadResourceRequestInvalidRequest**: The endpoint only accepts {valid_verbs} requests. Received a {invalid_verb} request. {valid_verbs} represents a list of HTTP verbs supported by the endpoint (for example, POST), {invalid_verb} is an HTTP verb used in the current request (for example, GET). This can be due to developer error, or due to users pressing the back button in their browser, triggering a bad request. It can be ignored.

Some Entra endpoints only take data in the body of a POST request. A browser that opens such a URL directly, from the address bar, a bookmark or the back button, sends a GET instead. Entra refuses it. The real message fills in the verbs, for example *"The endpoint only accepts POST, OPTIONS requests. Received a GET request."*

Two Microsoft-documented places where a POST is expected:

- **The token endpoint.** Microsoft's authorization code flow reference shows the code redemption as `POST /{tenant}/oauth2/v2.0/token` with a form-encoded body. Pasting a token request into a browser sends a GET. A user on Microsoft Q&A did exactly that with a device code token request and got 900561; the same request worked from curl.
- **External authentication methods (EAM).** Microsoft's provider reference says the call to the provider *"is made through a `POST` request because a large list of parameters gets passed to the provider"*, and that *"the provider needs to use `POST` to send a response back to the `redirect_uri`"*. Our reading: a provider that returns to `https://login.microsoftonline.com/common/federation/externalauthprovider` with a GET, or a user who reloads that step, gets 900561. SecureAuth's knowledge base describes intermittent 900561 errors with its product set up as an EAM.

## Is it an attack?

No. Microsoft says it *"can be ignored"*. It is a malformed request, and a malformed request gets nothing back.

| Pattern | Likely meaning |
|---|---|
| A single 900561 for a user, then a normal sign-in | Back button, a reloaded page or an old tab. Benign. |
| Users who open a saved login.microsoftonline.com URL | Our reading: a bookmark of a mid-sign-in URL would send a GET in the same way. Replace it with the app's own start URL. |
| Every user of an external MFA provider, or many of them | The hand-off between Entra and the provider is broken. Users report this with third-party EAM providers. An integration fault, not an attack. |
| One developer or script, repeatedly | A token request sent as GET, or a test pasted into a browser. Fix the client. |

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

Microsoft doesn't document whether 900561 is written to the sign-in logs. We assume the request often fails before Entra knows which user or app it belongs to, so there may be no row at all. SecureAuth's knowledge base says that for its EAM case the error is not recorded in the Entra sign-in or audit logs. Check whether your workspace has any:

```kusto
union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "900561"
| summarize Rows = count() by SourceTable
```

If rows exist, see which apps and clients produce them. `UserAgent` shows whether it is a browser or a script:

```kusto
SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == "900561"
| summarize Rows = count(), Users = dcount(UserPrincipalName), Messages = make_set(ResultDescription, 5)
          by AppDisplayName, AppId, UserAgent
| sort by Rows desc
```

If the union returns nothing, rely on what the user sees: the error page shows a correlation ID and a timestamp. `ResultType` is a **string** column, so compare it with `"900561"`, not `900561`.

## How do I fix AADSTS900561?

**For the user:** close the tab and start again from the app's own address, not from a bookmark, the browser history or the back button. If it happens at the MFA step every time, tell your IT helpdesk.

**For developers:**
1. Send token requests to `/oauth2/v2.0/token` as a POST with `Content-Type: application/x-www-form-urlencoded`, as in Microsoft's examples. A browser address bar can't do that.
2. If you build an external authentication method provider, return the response to the `redirect_uri` with a POST, as Microsoft's provider reference requires.

**For admins:**
1. A one-off is noise. Microsoft says it can be ignored.
2. Users who keep hitting it from a bookmark: give them the app's start URL instead.
3. Repeated errors at the MFA step with an external authentication method: collect the correlation ID and timestamp from the error page and raise it with the provider. SecureAuth's knowledge base suggests a HAR trace and comparing the `kid` of the `id_token_hint` with your tenant's published keys; if they don't match, it advises a Microsoft support case.

## 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/en-us/entra/identity-platform/reference-error-codes)
2. [Microsoft identity platform and OAuth 2.0 authorization code flow](https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow)
3. [Microsoft Entra multifactor authentication external method provider reference](https://learn.microsoft.com/entra/identity/authentication/concept-authentication-external-method-provider)
4. [SigninLogs table reference (Azure Monitor)](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs)
5. [Microsoft Q&A: Error AADSTS900561: The endpoint only accepts POST](https://learn.microsoft.com/en-us/answers/questions/938820/error-aadsts900561-the-endpoint-only-accepts-post)
6. [SecureAuth knowledge base: AADSTS900561 with SecureAuth as an external authentication method](https://support.secureauth.com/hc/en-us/articles/42577090596884)

## Related codes

[AADSTS9002313](https://brambrinkmeier.com/entra/aadsts/9002313/), [AADSTS900144](https://brambrinkmeier.com/entra/aadsts/900144/), [AADSTS90023](https://brambrinkmeier.com/entra/aadsts/90023/)

## 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, "AADSTS900561 fix: endpoint only accepts POST, got GET", https://brambrinkmeier.com/entra/aadsts/900561/ (CC BY 4.0), last updated 2026-11-01.