AADSTS700054 Response_Type Id_Token Is Not Enabled For The Application | Fix Steps That Work

Running into the AADSTS700054 message right after sign in can feel confusing, especially if authentication used to work. The good news is that this error points to a narrow configuration issue between your application and Microsoft Entra ID (Azure AD), so you can correct it without rewriting your whole sign in flow.

What The AADSTS700054 Error Actually Means

When you see AADSTS700054, Azure AD is telling you that the response_type parameter in your OpenID Connect or OAuth request asks for an id_token, but the application registration is not allowed to get that token from the authorization endpoint. In other words, the client asks for an identity token and the directory refuses because the app is not configured to receive it.

Most of the time, this appears in single page applications, older implicit flow setups, or any client that still uses a response like id_token or id_token token instead of the newer authorization code flow with PKCE. The request reaches Azure AD, the user account is valid, yet the platform blocks the response because the app registration flags for issuing ID tokens are off.

An id_token carries identity claims about the signed-in user, such as name, tenant, and unique object identifier, and it is meant for the client to validate that sign in succeeded. An access token, in contrast, is meant for APIs. When Azure AD blocks id_token responses for an app, the client cannot complete its sign in logic that depends on those user claims.

This is why the full message often reads almost the same as “AADSTS700054 response_type id_token is not enabled for the application.” You are not dealing with bad credentials or a broken tenant; you are dealing with an app registration that does not match the way your client library talks to the identity platform.

Why You See AADSTS700054 Response_Type Id_Token Is Not Enabled For The Application

Before you change any settings, it helps to connect the error to what your client actually sends. AADSTS700054 normally traces back to one of three patterns in real projects.

• Implicit Flow Still In Use — The application uses an older library or custom code that sends response_type=id_token or id_token token, but the app registration never enabled ID token issuance for that flow.
• New App Registration With Default Settings — You created a fresh app registration in Microsoft Entra ID, left the tokens section untouched, and then wired it to a sample or template that expects ID tokens.
• Mixed Configuration Between Flows — The application moved to authorization code flow with PKCE, yet some redirect URLs or secondary clients still send implicit requests that need ID tokens turned on.

In every case, the directory behaves as designed. It blocks the response_type and protects the tenant until an administrator explicitly allows ID tokens for that registration or adjusts the client so that it uses a safer flow.

Quick Checks Before You Change Azure Settings

Before you open the portal, it helps to confirm how your application talks to Azure AD. This reduces guesswork and keeps changes precise, especially in shared tenants where many registrations live side by side.

• Confirm The Client Library — Check whether you use MSAL, ADAL, a framework integration, or fully custom HTTP calls. The library version usually reveals which flow you use.
• Inspect The Response_Type — Capture one failing request with your browser developer tools or a proxy and inspect the response_type value. If you see id_token alone or together with token, you know why the platform complains.
• Identify The App Registration — Match the client_id in the request to the right app registration in Microsoft Entra ID so you do not toggle settings on the wrong application.

Once you have those three details clear, you can decide whether you want to enable ID tokens for the existing flow or change the client so that it uses the recommended authorization code pattern instead.

Fixing The Response_Type Id_Token Is Not Enabled Error In Your Azure App

For many teams, the most direct fix is to allow ID tokens for the registration that triggers AADSTS700054. This lines up the settings with the way your client already behaves, so you can confirm that the basic integration works before you plan a broader refactor.

Use the following steps if you choose to keep the implicit style request and simply enable ID tokens in the portal.

Enable Id_Token Issuance In The Azure Portal

• Open Microsoft Entra Id — Sign in to the Azure portal and go to Microsoft Entra ID, previously called Azure Active Directory.
• Locate Your App Registration — Under the App registrations section, filter by the Application (client) ID that appears in the failing request and open that registration.
• Go To The Authentication Blade — Select the Authentication page in the left menu where redirect URIs and token settings live.
• Find Token Selection Settings — In the part of the page that talks about tokens issued by the authorization endpoint, look for checkboxes related to ID tokens used for implicit and hybrid flows.
• Turn On Id Tokens — Check the ID tokens box so the authorization endpoint is allowed to send an id_token back when the response_type asks for it.
• Save Changes And Retry — Save the configuration, then run the same sign in path again to confirm that AADSTS700054 no longer appears.

Under the hood this change updates attributes on the app registration that control implicit grant behavior. You are telling the platform that this client is allowed to receive an ID token straight from the authorization endpoint when it requests one.

Set The Same Change Through The Manifest

Some administrators prefer to adjust settings as JSON through the manifest editor or automation scripts. The core idea matches the portal steps: turn on the flag that allows ID tokens.

• Open The Manifest Editor — On the same app registration, select the Manifest view so you can edit raw settings.
• Locate Implicit Grant Properties — Search within the JSON for properties such as oauth2AllowIdTokenImplicitFlow or the implicitGrantSettings section, depending on the current schema.
• Enable The Id Token Flag — Set the relevant value to true so the platform is allowed to send ID tokens by implicit flow.
• Save And Test Again — Save the manifest, reload your application, and repeat the sign in attempt to verify that the error disappears.

If your tenant uses source control or infrastructure as code for identity settings, updating these values through JSON or scripts keeps your fix repeatable across environments.

When You Should Change The Flow Instead Of The Setting

While enabling ID tokens removes the AADSTS700054 error quickly, it is worth asking whether your application should still rely on implicit flow at all. Microsoft recommends the authorization code flow with PKCE for most modern web apps and single page applications because it reduces exposure of tokens in the browser and supports richer scenarios.

If you already use a current MSAL library, you may only need a small configuration change so the client requests a code instead of an id_token directly.

• Check Library Samples — Review the official sample that matches your platform, such as React, Angular, or plain JavaScript, and compare the responseType and scopes used there.
• Switch Response Type To Code — Update client configuration so the request sends response_type=code, which aligns with authorization code flow and PKCE.
• Verify Redirect Uri And Backend Handling — Confirm that the redirect URI and server logic can trade the code for tokens through the token endpoint without leaking secrets to the browser.

After that change, the application no longer needs ID tokens from the authorization endpoint, so the specific AADSTS700054 complaint disappears even if ID tokens stay disabled on the app registration.

Code flow with PKCE shifts most security decisions to the token endpoint, which means tokens are not exposed in URL fragments and can be protected with server-side storage. For teams who handle sensitive data or run larger tenants, that pattern reduces the blast radius if a browser session is compromised.

• New Feature Work Ahead — When upcoming features require deeper API access or additional scopes, it is easier to extend an integration already based on code flow.
• Security Review Feedback — If internal or external reviewers question the use of implicit grant, switching to code flow with PKCE gives you a cleaner story during audits.
• Mobile Or Hybrid Clients — Apps that share logic between web and native layers align better when they all rely on the same authorization pattern.

Practical Examples Of Configuration Choices

Different projects reach this error from slightly different directions. The table below groups common situations and shows where to apply the fix so that AADSTS700054 response_type id_token is not enabled for the application stops interrupting sign in.

Seeing your own environment in one of these rows makes it much easier to decide whether to keep implicit behavior or move to a newer pattern while you clear the error.

Extra Troubleshooting When The Error Persists

Every now and then, an administrator enables ID tokens but the AADSTS700054 message still shows up. In these cases, the problem usually comes from small mismatches between the configuration and the request details.

• Check Redirect Uri Types — Confirm that the platform type for each redirect URI matches the client. A web redirect set as public client does not behave the same way as a SPA redirect.
• Match Tenants And Endpoints — Make sure the authority in the request uses the same tenant or common endpoint that the app registration expects, especially when you test in multiple directories.
• Clear Browser Cookies And Cache — Old sessions or cached frames sometimes keep sending stale parameters, so repeat the sign in with a clean session or private window.
• Review Conditional Access Policies — In rare cases a strict policy can change the way sign in behaves for certain users, so test with an account that has minimal policies attached.

If none of these checks remove the error, gather a fresh trace of the full authorization request and response and compare them with a known working sample. That comparison often reveals a small detail such as a mismatched client identifier, a missing scope, or a redirect URI that no longer exists.

When you do find the root cause, write down what changed and where. A record near the app registration or in your source repository helps the next person who sees AADSTS700054 connect the message to a clear fix instead of starting from a blank page for your team and documentation.

Send us your feedbackTell us what you thought about this post

⚠Please use a real email you check. If it's fake or mistyped, your message won't reach us and we can't reply — wrong addresses are rejected automatically.

Name *Email *

Your comment *

Quick check — what is …? *

Send feedback