AADSTS90014 fix: required field missing from the request

What does AADSTS90014 mean?

Microsoft’s description:

MissingRequiredField: This error code might appear in various cases when an expected field isn’t present in the credential.

Entra ID expected a field and didn’t find it. Microsoft doesn’t list the cases, but the message names the field, and that is where to start. Users report two forms:

• “AADSTS90014: The required field ‘scope’ is missing from the credential”, from ServiceNow using OAuth against a Microsoft API.
• “AADSTS90014: The required field ‘request’ is missing from the credential”, from a single-page app signing in through Azure AD B2C, and quoted in a moderator’s answer to a user signing in to school or work apps.

Compare 900144, which says “The request body must contain the following parameter” and also names what is missing. Microsoft doesn’t explain when Entra returns one code and not the other. Either way the fix is to supply what the message names. If the message is about resource instead, see 901002.

Is it an attack?

No documented attack pattern exists. The request is incomplete and no token is issued.

Pattern	Likely meaning
Field scope, from an integration or service account	A client credentials (or similar) token request without scope. Microsoft marks scope as Required in the client credentials flow. Configuration.
Field request, from a browser app, now and then	In the B2C thread the accepted answer said it “can be caused by navigating back after succesfuly loging-in”, and the developer confirmed the app navigated back right after sign-in. Our reading: the sign-in response was lost because the app left the page before handling it.
Field request, one user, a third-party app	The user pressed Back or reloaded during sign-in, or the app’s flow has the same bug. Not an attack.
90014 from one app, starting right after a release	The new version stopped sending a field.

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

Microsoft doesn’t document whether or where 90014 is logged. Check all three sign-in tables:

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

Which app is missing which field. We assume ResultDescription carries the message with the field name filled in; we haven’t seen a logged row:

union SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "90014"
| extend Field = extract(@"field '([^']+)'", 1, ResultDescription)
| summarize Rows = count(), Users = dcount(UserPrincipalName),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
          by AppDisplayName, ServicePrincipalName, AppId, Field
| sort by Rows desc

Apps that produced 90014 today but not in the previous 14 days. A FirstSeen right after a deployment points at the release:

let recent =
    union SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
    | where TimeGenerated > ago(1d)
    | where ResultType == "90014"
    | summarize Rows = count(), FirstSeen = min(TimeGenerated) by AppId, AppDisplayName;
let before =
    union SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
    | where TimeGenerated between (ago(15d) .. ago(1d))
    | where ResultType == "90014"
    | distinct AppId;
recent
| join kind=leftanti before on AppId
| sort by Rows desc

ResultType is a string column, so compare it with "90014", not 90014. In AADServicePrincipalSignInLogs the app name is in ServicePrincipalName, not AppDisplayName.

How do I fix AADSTS90014?

For the user:

1. Don’t press Back or reload while the sign-in page is working. Close the tab and start again from the app.
2. If it keeps happening, clear the browser’s cookies for the site and try again. That was the generic advice in the Q&A thread; one user said it didn’t help.
3. Still failing: report it to IT with the full message, including the field name.

For developers:

1. Read the field name in the error and add it.
2. scope in a client credentials request: send the API’s identifier with .default, for example https://graph.microsoft.com/.default. Microsoft: “All scopes included must be for a single resource.”
3. request in a browser app: let the app finish processing the sign-in response before it routes or navigates anywhere. The accepted answer in the B2C thread recommended a browser trace of the whole flow to see where it breaks.

For admins:

1. Use the second query to find the app and the field, and send both to the app’s owner.
2. For ServiceNow or another integration with an OAuth profile, check whether the profile sends a scope. ServiceNow documents the ‘scope’ form of this error in KB0866332.