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

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

**Short answer:** AADSTS700051 means an app asked the authorize endpoint for an access token directly (response_type=token, the implicit flow) but its app registration doesn't allow access tokens through the implicit flow. It is a configuration error with low attack value. Microsoft recommends against the implicit flow: move the app to the authorization code flow, or tick Access tokens if you can't yet.

**Fix:** User: report the app name to whoever runs it. Developer: move the app to the authorization code flow (`response_type=code`). Admin, only if the app can't move yet: App registrations > the app > Authentication > tick Access tokens under Implicit grant and hybrid flows, then Save.

| Field | Value |
|---|---|
| Code | AADSTS700051 |
| Category | App configuration |
| Type | Configuration error |
| Attack signal | Low: usually configuration or user error |
| In Microsoft's error reference | No (checked 2026-10-30) |
| Verification | lab-reproduced (2026-10-30) |
| Last updated | 2026-10-30 |

## What does AADSTS700051 mean?

Microsoft's [error code reference](https://learn.microsoft.com/entra/identity-platform/reference-error-codes) 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](https://brambrinkmeier.com/entra/aadsts/700054/), 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](https://brambrinkmeier.com/methodology/)). 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](https://learn.microsoft.com/en-us/answers/questions/519324/when-trying-to-create-token-for-implicit-flow-gett): 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:

```kusto
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:

```kusto
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.

## Evidence

Reproduced in a lab tenant on 2026-10-30 (Authorize request in a browser against a lab tenant; scenario: Implicit access token requested, implicit grant not enabled (browser)). First line returned:

> AADSTS700051: response_type 'token' is not enabled for the application.

Sign-in log row read: 2026-10-30. KQL run against the exported lab rows: 2026-10-30.

Lab-run rows naming this code (1; full list at https://brambrinkmeier.com/lab-runs.json):

| Date | Scenario | Expected | Got | Message (first line) |
|---|---|---|---|---|
| 2026-10-30 | Implicit access token requested, implicit grant not enabled (browser) | 700051 | 700051 | AADSTS700051: response_type 'token' is not enabled for the application. |

## Sources

1. [Microsoft Entra authentication and authorization error codes](https://learn.microsoft.com/entra/identity-platform/reference-error-codes)
2. [Microsoft identity platform and the OAuth 2.0 implicit grant flow](https://learn.microsoft.com/entra/identity-platform/v2-oauth2-implicit-grant-flow)
3. [Microsoft Q&A: When trying to create token for implicit flow getting AADSTS700051](https://learn.microsoft.com/en-us/answers/questions/519324/when-trying-to-create-token-for-implicit-flow-gett)
4. [SigninLogs table reference (Azure Monitor)](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs)
5. [AuditLogs table reference (Azure Monitor)](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/auditlogs)

## Related codes

[AADSTS700054](https://brambrinkmeier.com/entra/aadsts/700054/), [AADSTS500113](https://brambrinkmeier.com/entra/aadsts/500113/), [AADSTS50011](https://brambrinkmeier.com/entra/aadsts/50011/), [AADSTS700016](https://brambrinkmeier.com/entra/aadsts/700016/)

## 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, "AADSTS700051: Access tokens not enabled for the app (fix)", https://brambrinkmeier.com/entra/aadsts/700051/ (CC BY 4.0), last updated 2026-10-30.