AADSTS9002313: Request is malformed or invalid (fix)

What does AADSTS9002313 mean?

Microsoft’s description:

InvalidRequest: Request is malformed or invalid. - The issue arises because there was something wrong with the request to a certain endpoint. The suggestion to this issue is to get a fiddler trace of the error occurring and looking to see if the request is properly formatted or not.

The request never got as far as checking a password or a secret. Something in how it was built was wrong, so Microsoft Entra ID rejected it as a request.

Microsoft’s description doesn’t say which part of the request is wrong. That is the hard part of this code: it is generic. The OAuth 2.0 protocol error that goes with this kind of problem is invalid_request, which the authorization code flow reference describes as a “Protocol error, such as a missing required parameter.” Its advice for the client: “Fix and resubmit the request. This error is a development error typically caught during initial testing.” Our reading is that 9002313 is the AADSTS code behind many of those invalid_request responses, but Microsoft doesn’t publish that mapping.

Is it an attack?

Almost never. A malformed request gets the sender nothing, and Microsoft treats the code as a request-formatting problem.

Pattern	Likely meaning
9002313 for one app, starting right after a deployment or library update	The new version builds its requests differently. A regression in the app.
9002313 for every user of one app, from the start	The integration was never built correctly. Common with hand-written OAuth code.
9002313 for one user only	Something specific to that user’s request, such as a stale bookmark to a sign-in URL or a broken browser extension. Likely, but unconfirmed.
9002313 from an IP you don’t know, for an app ID you don’t recognise	Someone’s tooling is building bad requests against your tenant. Our interpretation: it is worth a look at what else that IP did, but the 9002313 itself is not harmful.

There is no documented attack pattern for 9002313. Keep it out of password spray detections, because it says nothing about credentials.

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

Microsoft doesn’t document which sign-in table 9002313 is logged in, or whether every malformed request produces a sign-in log row at all. Start by checking where it lands in your workspace:

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

Which apps send the malformed requests, and since when. A sudden start date usually points at a release:

union SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "9002313"
| summarize Rows = count(),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated),
            IPs = dcount(IPAddress),
            Descriptions = make_set(ResultDescription, 5)
          by AppId, AppDisplayName = coalesce(AppDisplayName, ServicePrincipalName)
| sort by Rows desc

Check ResultDescription in the output. It may carry more detail than the generic reference text, such as the name of the parameter that was wrong. Whether it does isn’t documented, so treat it as a bonus if it’s there.

Non-interactive and service principal rows are aggregated when application, user (or service principal), IP address, status and resource match, so row counts in those tables are not request counts. ResultType is a string column, so compare it with "9002313", not 9002313.

How do I fix AADSTS9002313?

For the user: this isn’t something you caused with your password. If an old bookmark or saved link starts the sign-in, open the app from its normal start page instead. If the error stays, report it to whoever runs the app with the time it happened.

For developers:

1. Do what Microsoft suggests: capture the failing request with Fiddler (or your browser’s developer tools) and check it parameter by parameter against the protocol reference for that endpoint.
2. Check that the request goes to the right endpoint for its parameters. A v2.0 parameter such as scope sent to a v1 endpoint, or the reverse, is a typical way to build an invalid request. That is our example, not one Microsoft lists for this code.
3. Check encoding. Values in a token request body must be form-encoded; a raw +, & or space in a secret or redirect URI breaks the request. Again our example, not a Microsoft statement.
4. Prefer a Microsoft Authentication Library (MSAL) over hand-written requests. It builds the protocol messages for you.

For admins:

1. Use the second query to find the app and the date it started. Hand both to the app owner or vendor.
2. If the app is a third-party SaaS integration, the request is built on the vendor side. Open a ticket with them and include the correlation ID and timestamp from the sign-in log row.
3. If the app ID is unknown to you, check whether it has a service principal in your tenant before deciding it is harmless. A related code for an app that isn’t there is 700016.