Skip to content

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

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. Full steps

At a glance
CodeAADSTS700054
CategoryApp configuration
TypeConfiguration error
Attack signalLow: usually configuration or user error
Where to lookSigninLogs
Microsoft lookuplogin.microsoftonline.com/error?code=700054

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 as at least a 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.

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.

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:

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:

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).

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.

Sources

  1. Microsoft Entra authentication and authorization error codes
  2. Microsoft identity platform and the OAuth 2.0 implicit grant flow
  3. Microsoft identity platform and OAuth 2.0 authorization code flow
  4. SigninLogs table reference (Azure Monitor)