{
  "schemaVersion": "1.0",
  "code": "700051",
  "name": null,
  "title": "AADSTS700051: Access tokens not enabled for the app (fix)",
  "url": "https://brambrinkmeier.com/entra/aadsts/700051/",
  "alternates": {
    "markdown": "https://brambrinkmeier.com/entra/aadsts/700051.md",
    "json": "https://brambrinkmeier.com/api/aadsts/700051.json",
    "html": "https://brambrinkmeier.com/entra/aadsts/700051/"
  },
  "description": "AADSTS700051: the app asked for an implicit access token (response_type=token) but it isn't enabled. A config error; move to auth code flow.",
  "summary": "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.",
  "inMicrosoftReference": false,
  "unlistedChecked": "2026-10-30",
  "meaningText": "Microsoft's [error code reference](https://learn.microsoft.com/entra/identity-platform/reference-error-codes) doesn't list AADSTS700051 (checked 30 October 2026).\n\nIn 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:\n\n> AADSTS700051: response_type 'token' is not enabled for the application.\n\n`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.\n\nThe 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.\n\nIts documented sibling is [AADSTS700054](https://brambrinkmeier.com/entra/aadsts/700054/), the same refusal for `response_type=id_token`, which Microsoft does list.",
  "sections": [
    {
      "heading": "What does AADSTS700051 mean?",
      "text": "Microsoft's [error code reference](https://learn.microsoft.com/entra/identity-platform/reference-error-codes) doesn't list AADSTS700051 (checked 30 October 2026).\n\nIn 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:\n\n> AADSTS700051: response_type 'token' is not enabled for the application.\n\n`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.\n\nThe 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.\n\nIts documented sibling is [AADSTS700054](https://brambrinkmeier.com/entra/aadsts/700054/), the same refusal for `response_type=id_token`, which Microsoft does list."
    },
    {
      "heading": "Reproduced in the lab",
      "text": "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:\n\n> AADSTS700051: response_type 'token' is not enabled for the application.\n\nThat 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."
    },
    {
      "heading": "Is it an attack?",
      "text": "No. It is an app that uses a flow its registration doesn't allow.\n\n| Pattern | Likely meaning |\n|---|---|\n| 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. |\n| 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. |\n| An app that worked and now fails | Someone disabled the implicit grant on the registration. Check the audit log (query below). |\n\nAs 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."
    },
    {
      "heading": "How do I find it in my logs (KQL)?",
      "text": "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:\n\n```kusto\nunion withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs\n| where TimeGenerated > ago(30d)\n| where ResultType == \"700051\"\n| summarize Rows = count(), LastSeen = max(TimeGenerated) by SourceTable, AppId, AppDisplayName\n```\n\nIf the app used to work, find who changed its registration:\n\n```kusto\nAuditLogs\n| where TimeGenerated > ago(90d)\n| where OperationName == \"Update application\"\n| mv-expand Target = TargetResources\n| where tostring(Target.displayName) == \"<app display name>\"\n| mv-expand Prop = Target.modifiedProperties\n| project TimeGenerated,\n    Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)),\n    Property = tostring(Prop.displayName),\n    OldValue = tostring(Prop.oldValue),\n    NewValue = tostring(Prop.newValue)\n| sort by TimeGenerated desc\n```\n\nThe 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."
    },
    {
      "heading": "How do I fix AADSTS700051?",
      "text": "**For the user:** you can't fix this yourself. Report the app name to whoever runs it.\n\n**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.\n\n**For admins**, only if the app can't move yet:\n1. In the Microsoft Entra admin center, open **App registrations** and select the app.\n2. Select **Authentication**.\n3. Under **Implicit grant and hybrid flows**, select **Access tokens**, and **ID tokens** too if the app also requests `id_token`.\n4. Save.\n\nMicrosoft 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."
    }
  ],
  "microsoftWording": {
    "text": "AADSTS700051: response_type 'token' is not enabled for the application.",
    "source": "Quoted on the page from the lab or from user reports; the code is not in Microsoft's error code reference",
    "sourceUrl": null
  },
  "securityReading": {
    "category": {
      "id": "app-config",
      "label": "App configuration"
    },
    "kind": {
      "id": "config",
      "label": "Configuration error"
    },
    "attackSignal": {
      "level": "low",
      "label": "Low: usually configuration or user error"
    },
    "mitre": [],
    "tables": [],
    "isItAnAttack": "No. It is an app that uses a flow its registration doesn't allow.\n\n| Pattern | Likely meaning |\n|---|---|\n| 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. |\n| 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. |\n| An app that worked and now fails | Someone disabled the implicit grant on the registration. Check the audit log (query below). |\n\nAs 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.",
    "conditionalAccess": null
  },
  "kql": [
    {
      "title": null,
      "leadIn": "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:",
      "query": "union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs\n| where TimeGenerated > ago(30d)\n| where ResultType == \"700051\"\n| summarize Rows = count(), LastSeen = max(TimeGenerated) by SourceTable, AppId, AppDisplayName"
    },
    {
      "title": null,
      "leadIn": "If the app used to work, find who changed its registration:",
      "query": "AuditLogs\n| where TimeGenerated > ago(90d)\n| where OperationName == \"Update application\"\n| mv-expand Target = TargetResources\n| where tostring(Target.displayName) == \"<app display name>\"\n| mv-expand Prop = Target.modifiedProperties\n| project TimeGenerated,\n    Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)),\n    Property = tostring(Prop.displayName),\n    OldValue = tostring(Prop.oldValue),\n    NewValue = tostring(Prop.newValue)\n| sort by TimeGenerated desc"
    }
  ],
  "kqlSectionText": "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:\n\n```kusto\nunion withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs\n| where TimeGenerated > ago(30d)\n| where ResultType == \"700051\"\n| summarize Rows = count(), LastSeen = max(TimeGenerated) by SourceTable, AppId, AppDisplayName\n```\n\nIf the app used to work, find who changed its registration:\n\n```kusto\nAuditLogs\n| where TimeGenerated > ago(90d)\n| where OperationName == \"Update application\"\n| mv-expand Target = TargetResources\n| where tostring(Target.displayName) == \"<app display name>\"\n| mv-expand Prop = Target.modifiedProperties\n| project TimeGenerated,\n    Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)),\n    Property = tostring(Prop.displayName),\n    OldValue = tostring(Prop.oldValue),\n    NewValue = tostring(Prop.newValue)\n| sort by TimeGenerated desc\n```\n\nThe 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.",
  "fix": {
    "short": "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.",
    "steps": "**For the user:** you can't fix this yourself. Report the app name to whoever runs it.\n\n**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.\n\n**For admins**, only if the app can't move yet:\n1. In the Microsoft Entra admin center, open **App registrations** and select the app.\n2. Select **Authentication**.\n3. Under **Implicit grant and hybrid flows**, select **Access tokens**, and **ID tokens** too if the app also requests `id_token`.\n4. Save.\n\nMicrosoft 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."
  },
  "labReproduced": {
    "date": "2026-10-30",
    "method": "Authorize request in a browser against a lab tenant",
    "scenario": "Implicit access token requested, implicit grant not enabled (browser)",
    "message": "AADSTS700051: response_type 'token' is not enabled for the application.",
    "logCaptured": "2026-10-30",
    "kqlTested": "2026-10-30"
  },
  "labSectionText": "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:\n\n> AADSTS700051: response_type 'token' is not enabled for the application.\n\nThat 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.",
  "labRuns": [
    {
      "date": "2026-10-30",
      "run": null,
      "method": "Authorize request in a browser against a lab tenant",
      "issue": "https://github.com/GrantZero604/Brambrinkmeier.com/issues/66",
      "scenario": "Implicit access token requested, implicit grant not enabled (browser)",
      "expected": "700051",
      "got": "700051",
      "matchedExpectation": true,
      "message": "AADSTS700051: response_type 'token' is not enabled for the application."
    }
  ],
  "verification": "lab-reproduced",
  "related": [
    "700054",
    "500113",
    "50011",
    "700016"
  ],
  "coveredBy": [],
  "sources": [
    {
      "title": "Microsoft Entra authentication and authorization error codes",
      "url": "https://learn.microsoft.com/entra/identity-platform/reference-error-codes"
    },
    {
      "title": "Microsoft identity platform and the OAuth 2.0 implicit grant flow",
      "url": "https://learn.microsoft.com/entra/identity-platform/v2-oauth2-implicit-grant-flow"
    },
    {
      "title": "Microsoft Q&A: When trying to create token for implicit flow getting AADSTS700051",
      "url": "https://learn.microsoft.com/en-us/answers/questions/519324/when-trying-to-create-token-for-implicit-flow-gett"
    },
    {
      "title": "SigninLogs table reference (Azure Monitor)",
      "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs"
    },
    {
      "title": "AuditLogs table reference (Azure Monitor)",
      "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/auditlogs"
    }
  ],
  "published": "2026-10-30",
  "lastUpdated": "2026-10-30",
  "lastVerified": null,
  "license": "CC BY 4.0",
  "licenseUrl": "https://creativecommons.org/licenses/by/4.0/",
  "licenseNote": "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.",
  "attribution": "Bram Brinkmeier, \"AADSTS700051: Access tokens not enabled for the app (fix)\", https://brambrinkmeier.com/entra/aadsts/700051/ (CC BY 4.0)",
  "microsoftErrorLookup": "https://login.microsoftonline.com/error?code=700051"
}