AADSTS900561 fix: endpoint only accepts POST, got GET

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:

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:

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.