AADSTS700051: Access tokens not enabled for the app (fix)

What does AADSTS700051 mean?

Microsoft’s error code reference doesn’t list AADSTS700051 (checked 30 October 2026).

In my lab tenant, an unauthenticated authorize request in a browser with response_type=token, for an app registration without the implicit grant for access tokens, showed this error on the page:

AADSTS700051: response_type ‘token’ is not enabled for the application.

response_type=token is the implicit flow: the app gets an access token straight from the /authorize endpoint. Microsoft’s implicit grant page says the app registration “must have the corresponding implicit grant flow enabled, by selecting ID tokens and access tokens in the Implicit grant and hybrid flows section.” 700051 is what the lab got when Access tokens was not selected.

The same Microsoft page gives a different message for this case: “If it’s not enabled, an unsupported_response error will be returned: The provided value for the input parameter ‘response_type’ is not allowed for this client. Expected value is ‘code’”. The lab got the 700051 text instead. Our reading: the page’s example is a different or older message, or comes with a different request. Expect the 700051 wording.

Its documented sibling is AADSTS700054, the same refusal for response_type=id_token, which Microsoft does list.

Reproduced in the lab

In a manual lab test on 30 October 2026, an authorize URL with response_type=token for a lab app registration without implicit access tokens was opened in a private browser window, without signing in. Entra showed AADSTS700051 on its error page with this first line:

AADSTS700051: response_type ‘token’ is not enabled for the application.

That confirms the code and its wording at the authorize endpoint. It also shows the error doesn’t need a signed-in user: the request was unauthenticated. It lands in SigninLogs, logged under the account already signed in to that browser (the lab admin). Entra’s explanation on the row reads: “The application requested an unsupported response type due to the following reasons: response_type ‘token’ is not enabled for the application. Application owner should go to the Azure portal or call MS Graph to enable the implicit access token grant.” The row shows client app “Mobile Apps and Desktop clients” even though the request came from a browser. The field likely follows the app’s registration, not the request, but that is unconfirmed. The KQL below was run on these rows (how). The first query found the rows. The AuditLogs query isn’t tested: the export has no audit rows.

Is it an attack?

No. It is an app that uses a flow its registration doesn’t allow.

Pattern	Likely meaning
An older single-page app or a JavaScript library that uses the implicit flow	The registration never had Access tokens ticked, or someone unticked it to retire the implicit flow.
A developer testing in Postman or a script	Users report this on Microsoft Q&A: sign-in worked in the browser, the implicit token request from Postman failed with 700051.
An app that worked and now fails	Someone disabled the implicit grant on the registration. Check the audit log (query below).

As far as we can tell, the request is refused before anyone signs in and nothing is issued. Disabling the implicit grant is a hardening step, so a burst of 700051 after a cleanup tells you which apps still depend on it.

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

Microsoft doesn’t document which sign-in table 700051 is logged in. In the lab it was logged in SigninLogs, under the account that already had a browser session. A request with no session may leave no row at all. Check both user sign-in tables:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "700051"
| summarize Rows = count(), LastSeen = max(TimeGenerated) by SourceTable, AppId, AppDisplayName

If the app used to work, find who changed its registration:

AuditLogs
| where TimeGenerated > ago(90d)
| where OperationName == "Update application"
| mv-expand Target = TargetResources
| where tostring(Target.displayName) == "<app display name>"
| mv-expand Prop = Target.modifiedProperties
| project TimeGenerated,
    Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)),
    Property = tostring(Prop.displayName),
    OldValue = tostring(Prop.oldValue),
    NewValue = tostring(Prop.newValue)
| sort by TimeGenerated desc

The table reference documents TargetResources and InitiatedBy only as dynamic columns. The field names inside them and the operation name Update application are our reading of how Entra fills them. Look for a property that changed from true to false around the time the errors started.

How do I fix AADSTS700051?

For the user: you can’t fix this yourself. Report the app name to whoever runs it.

For developers: move the app to the authorization code flow. Microsoft: “We strongly recommend that all new applications use the authorization code flow that now supports single-page apps in place of the implicit flow. Existing single-page apps should also migrate to the authorization code flow.” With the code flow the app sends response_type=code, and this error goes away without enabling anything.

For admins, only if the app can’t move yet:

1. In the Microsoft Entra admin center, open App registrations and select the app.
2. Select Authentication.
3. Under Implicit grant and hybrid flows, select Access tokens, and ID tokens too if the app also requests id_token.
4. Save.

Microsoft is clear that this is a trade-off: “Microsoft recommends you do not use the implicit grant flow. In most scenarios, more secure alternatives are available and recommended.” Treat enabling it as a temporary exception, and record who owns the migration.