# AADSTS700054: ID tokens not enabled for the app (fix)

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

**Short answer:** AADSTS700054 means an app asked the authorize endpoint for an ID token (response_type id_token) but its app registration doesn't allow ID tokens through the implicit or hybrid flow. It is a configuration error with low attack value. Either tick ID tokens in the app registration, or better, move the app to the authorization code flow.

**Fix:** User: report the app name and the time to whoever runs the app. Developer: move to the authorization code flow with PKCE. Admin, only if the app must keep the implicit or hybrid flow: App registrations > the app > Authentication > tick ID tokens under Implicit grant and hybrid flows.

| Field | Value |
|---|---|
| Code | AADSTS700054 |
| Category | App configuration |
| Type | Configuration error |
| Attack signal | Low: usually configuration or user error |
| Where to look | `SigninLogs` |
| In Microsoft's error reference | Yes |
| Verification | documentation |
| Last updated | 2026-10-30 |

## What does AADSTS700054 mean?

Microsoft's description:

> Response_type 'id_token' isn't enabled for the application. The application requested an ID token from the authorization endpoint, but did not have ID token implicit grant enabled. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#cloud-application-administrator) and then browse to **Entra ID** > **App registrations**. Select your application and then select **Authentication**. Under **Implicit grant and hybrid flows**, make sure **ID tokens'** is selected.

The app sent `response_type=id_token` (alone, or as `code id_token`) to the `/authorize` endpoint. The app registration says ID tokens may not be returned from that endpoint. Entra refuses before any token is issued.

Two flows do this. The implicit flow: Microsoft's implicit grant page says `response_type` *"Must include `id_token` for OpenID Connect sign-in"*, and that 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."* And the hybrid flow: the authorization code flow page says *"You can also receive an ID token if you request one and have the implicit grant enabled in your application registration. This behavior is sometimes referred to as the hybrid flow."*

The protocol error the app sees may be `unsupported_response` or `unsupported_response_type`, depending on the page you read. Microsoft's auth code flow page says that in the hybrid flow `unsupported_response_type` *"signals that you must enable the ID token implicit grant setting on the client app registration."* Our reading: the AADSTS700054 code is the same event, in the `error_codes` field of the response.

## Is it an attack?

No. It is a mismatch between what the app asks for and what its registration allows.

| Pattern | Likely meaning |
|---|---|
| One app, all users, starting on a specific day | The app was deployed or reconfigured to use the implicit or hybrid flow, and the registration wasn't updated. Or someone unticked **ID tokens**. |
| One app, after someone cleaned up the registration | ID tokens were turned off on purpose, but the app still uses the old flow. |
| An app you don't recognise | Possibly someone is using your app's client ID with a different flow (unconfirmed). Check whether the redirect URI and client ID are your own. Still a refusal, not a breach. |

As far as we can tell, nothing is issued when this error fires, so there is no token for an attacker to capture.

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

Microsoft doesn't document which sign-in table 700054 is logged in. It happens at the interactive authorize endpoint, so `SigninLogs` is the most likely table (our assumption). Check:

```kusto
union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "700054"
| summarize Rows = count(), Users = dcount(UserPrincipalName) by SourceTable
```

Which apps hit it, since when, and from which clients:

```kusto
SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == "700054"
| summarize Rows = count(),
            Users = dcount(UserPrincipalName),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated),
            Agents = make_set(UserAgent, 5)
          by AppDisplayName, AppId
| sort by Users desc
```

`FirstSeen` is useful: put it next to the app registration's change history in the Entra audit log to see what changed. If the user name is empty in these rows, the error came before the user signed in (our assumption, not yet checked against real data).

## How do I fix AADSTS700054?

**For the user:** you can't fix this yourself. Report the app name and the time to whoever runs the app.

**For developers:** Microsoft recommends against the flow that needs this setting. The implicit grant page says: *"We strongly recommend that all new applications use the authorization code flow that now supports single-page apps in place of the implicit flow."* For a single-page app, use the authorization code flow with PKCE; the auth code flow page says PKCE is *"required by the Microsoft identity platform for single page apps using the authorization code flow."* MSAL.js 2 and later does this for you. If you really need an ID token from `/authorize` (hybrid flow), ask the app admin to enable **ID tokens**, and include `openid` in `scope` and a `nonce`.

**For admins:**
1. Find the app with the second query.
2. Ask the developer which flow the app uses. If it can move to the authorization code flow, do that and leave the implicit setting off.
3. If the app must keep the implicit or hybrid flow: Entra admin center > **Entra ID** > **App registrations** > the app > **Authentication** > **Implicit grant and hybrid flows** > tick **ID tokens**. Tick **Access tokens** only if the app also requests access tokens from `/authorize`.

## Evidence

Not reproduced in the lab yet; the page is based on Microsoft's documentation.

## Sources

1. [Microsoft Entra authentication and authorization error codes](https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes)
2. [Microsoft identity platform and the OAuth 2.0 implicit grant flow](https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-implicit-grant-flow)
3. [Microsoft identity platform and OAuth 2.0 authorization code flow](https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow)
4. [SigninLogs table reference (Azure Monitor)](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs)

## Related codes

[AADSTS50011](https://brambrinkmeier.com/entra/aadsts/50011/), [AADSTS700016](https://brambrinkmeier.com/entra/aadsts/700016/), [AADSTS54005](https://brambrinkmeier.com/entra/aadsts/54005/), [AADSTS500113](https://brambrinkmeier.com/entra/aadsts/500113/), [AADSTS700051](https://brambrinkmeier.com/entra/aadsts/700051/), [AADSTS9002327](https://brambrinkmeier.com/entra/aadsts/9002327/)

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