Request a trial
Menu
Products
Solutions
ERP
Authentication
Apps
LearnDocsWhy SSOGENRequest a trial

SSOGEN / Free tools / AADSTS700016: Application Not Found in the Directory, Fixed Step by Step

Free tool

AADSTS700016: Application Not Found in the Directory, Fixed Step by Step

AADSTS700016 means Microsoft Entra ID found no application with the client ID in your request inside the tenant you sent it to. Paste the error into the free reader below to see the IDs it names, then work through the ranked causes.

Plan a trial

Read the error you have

Paste the full error text into the box: the message on the sign-in page, the error_description in a redirect, or a line from the sign-in log.

The tool finds the AADSTS code, Trace ID, Correlation ID and timestamp, lists the accounts and IDs the message names, and prints the checks for that code.

For this code it also extracts the application identifier and the directory from the sentence “Application with identifier … was not found in the directory …”.

To see exactly what your app sent, capture the sign-in and open it in the HAR file analyzer.

The message from the sign-in page, the error_description in a redirect, or a line from the sign-in log. It starts with AADSTS and a number.

Private by design. Reading happens in this page and nothing is sent anywhere. The text can hold email addresses, tenant names and IDs: use a copy you are allowed to look at. Real messages vary in wording; the samples are shortened.

Free, in your browser. No sign-up, and nothing is sent anywhere when you read an error.

The text can contain email addresses, tenant names and IDs, so paste a copy you are allowed to share. The Acme samples (acme.example is a reserved example domain) are shortened; real messages vary in wording.

The tool never reads your tenant. It reads only the text you paste, so it cannot know whether the app exists.

What AADSTS700016 is

AADSTS700016 is what Microsoft Entra ID returns when the sign-in request names an application (by client ID) that does not exist in the tenant it was sent to. Microsoft’s error list calls it UnauthorizedClient_DoesNotMatchRequest. It has three causes:

  • The ID in the request is wrong.
  • The request went to the wrong tenant.
  • The app exists, but nobody installed it or consented to it in that tenant.

The reader above extracts the IDs from the message so you can see which cause applies.

What the error says

Microsoft’s error-code reference (read 2026-10-11) says AADSTS700016 means the application was not found in the directory or tenant. It lists four reasons:

  • Not installed. The tenant’s administrator has not installed the application.
  • Not consented. No user in the tenant has consented to it.
  • Wrong identifier. The application identifier value is misconfigured.
  • Wrong tenant. The authentication request was sent to the wrong tenant.

A typical message, with Acme values:

AADSTS700016: Application with identifier '3f2a9c10-7b1e-4c55-9d02-6a1b8e4c7d90'
was not found in the directory 'Acme Partners'. This can happen if the application
has not been installed by the administrator of the tenant or consented to by any
user in the tenant. You may have sent your authentication request to the wrong tenant.

Two values matter:

  • The identifier is whatever the app sent as client_id.
  • The directory is the tenant the request was addressed to.

The error is about the pair: this ID does not exist in this directory. It does not say which half is wrong, which is why the ranking below matters.

The app can also receive the same failure as a redirect with error=unauthorized_client. The AADSTS number is inside error_description.

Microsoft’s authorization code flow page says that code usually appears when the client application is not registered in Microsoft Entra ID or is not added to the user’s tenant.

Causes, ranked

This order is our judgment of how these errors happen in practice, not a count from Microsoft. Work down the list; each check takes a minute.

Rank Cause How to check it
1 The client_id is not the Application (client) ID. A secret value, an object ID or a tenant ID was pasted into the setting. The identifier in the message must be a GUID. If it is not, you sent something else.
2 The ID is right but the request went to a different tenant than the one where the app is registered Compare the tenant in the authority address with the Directory (tenant) ID of the registration.
3 A multitenant app has no enterprise application in the customer’s tenant, because nobody there has consented Search Enterprise applications in that tenant for the app. Not found means it was never installed or consented.
4 The app registration was deleted, or lives in a tenant you are not signed in to Search App registrations in each tenant you can reach, using the ID from the message.
5 The ID has a typo, a stray space or a copy from the wrong environment (test registration, production tenant) Compare it character by character with the Overview page.
6 The app is single-tenant, and a person from another tenant is trying to sign in through a tenant-specific address that is not their own Check the sign-in audience on the registration and the address the app builds.

Cause 1: the wrong value in the client ID setting

Check this cause first, because the error message shows it directly. The identifier in the text is exactly what your app sent. A client ID is a GUID such as 3f2a9c10-7b1e-4c55-9d02-6a1b8e4c7d90.

In a Microsoft Q&A thread (read 2026-10-11), the identifier in the error was a string shaped like a client secret, not a GUID. The accepted fix was to replace it with the Application (client) ID from the registration.

If the identifier in your error is not a GUID, also treat the string as a leaked secret. It now appears in logs and tickets, so create a new secret and delete the old one.

Cause 2: the right app, the wrong tenant

The sign-in address has a tenant segment: https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize. Microsoft’s OAuth and OpenID Connect protocols page says that value controls who can sign in. The allowed values are:

  • common for work or school accounts and personal Microsoft accounts;
  • organizations for work or school accounts only;
  • consumers for personal Microsoft accounts only;
  • a tenant identifier (the tenant ID or a domain name).

If your configuration holds the wrong tenant ID, or a domain that belongs to another tenant, Entra ID does not find the app there.

Microsoft’s authorization code page adds one more rule: in guest scenarios, where you sign a user from one tenant into another, you must give the tenant identifier of the resource tenant.

Authority value Who it lets in (per Microsoft)
/{tenant ID or domain} Accounts of that tenant
/organizations Work or school accounts only
/consumers Personal Microsoft accounts only
/common Work or school accounts and personal Microsoft accounts

Cause 3: a multitenant app that was never added to the customer’s tenant

An app registration lives in one home tenant.

Microsoft’s documentation on application and service principal objects describes the rest. A service principal, the object shown as an enterprise application, is created in every tenant where the app is used.

For a multitenant app, that happens when a user from that tenant consents.

Until then, the customer’s directory has no object with that ID, and sign-in fails with this error. This is the situation Microsoft’s message describes with “not installed by the administrator or consented to by any user”.

Causes 4 to 6: deleted, mistyped, or the wrong audience

Microsoft notes that deleting an application object also deletes its home-tenant service principal, and restoring the registration does not bring the service principal back. If an app worked before and has stopped, look for a deletion first.

On audience, the registration has a supported account type. Microsoft’s tables name the options:

  • single tenant only (accounts in this organizational directory only);
  • multiple Entra ID tenants;
  • any Entra ID tenant plus personal Microsoft accounts;
  • personal accounts only.

Single-tenant apps are available only in the tenant where they were registered.

Fix it, step by step

Portal names below come from Microsoft Learn pages read on 2026-10-11. Microsoft renames menu items from time to time.

  1. Copy the identifier and the directory from the error. The reader above lists both.
  2. Sign in to the Microsoft Entra admin center. Browse to Entra ID, then App registrations. If you can reach several tenants, use the Settings icon in the top menu to switch tenant from the Directories + subscriptions menu.
  3. Search for the identifier. If a registration appears, open it. The Overview page shows the Application (client) ID. Compare it with the setting in your app. If they differ, fix the app’s configuration.
  4. If no registration appears, the current tenant does not hold it. Switch tenants and search again. A vendor’s multitenant app does not appear in your App registrations; look under Enterprise apps instead.
  5. If the app lives in a different tenant from the one in the failing request, change the tenant segment of the authority address to the tenant where the app is registered, or where it has been consented to.
  6. For a multitenant app in a customer tenant, have an administrator grant consent. Microsoft’s admin consent page gives two portal routes. In Enterprise apps, then All applications, open the app, select Permissions under Security, review them and select Grant admin consent. In App registrations, open the app, select API permissions under Manage, review and select Grant admin consent. The first route needs the app to exist in the tenant already.
  7. If the app is not in the tenant at all, build the admin consent address from the ID, as Microsoft’s page describes: https://login.microsoftonline.com/{organization}/adminconsent?client_id={client-id}. {organization} is the tenant ID or a verified domain of the tenant you are consenting in. Have an administrator sign in at that address.
  8. Send the sign-in again in a private window.

Tenant-wide consent is a sensitive step. Microsoft’s page warns it can give the publisher access to significant parts of your organization’s data, so review the requested permissions first.

Roles that can grant it include Privileged Role Administrator, and Cloud Application Administrator or Application Administrator for most permissions.

A new registration in your own tenant is different: its enterprise application is created automatically. Microsoft’s documentation says registering an app in the portal creates both the application object and the service principal in your home tenant.

Where to find the IDs

Value Where it is Used for
Application (client) ID App registrations, the app, Overview The client_id in every sign-in request
Directory (tenant) ID Copied from the app registration The tenant segment of the authority address
Enterprise application Enterprise apps, All applications, the app name The tenant’s local copy of the app, where consent and assignments live

An app registration also links to its local copy: select Managed application in local directory on the Overview page, as Microsoft’s documentation describes.

Where this meets SSOGEN

When Entra ID is the identity provider for SSOGEN, this error can appear during setup.

  • SAML route. AADSTS700016 means Entra finds no application with the identifier SSOGEN sent. Set the Identifier in Entra’s Basic SAML Configuration to SSOGEN’s SP entity ID, character for character. The Add SAML Provider wizard shows that ID once the connection ID is valid.
  • OpenID Connect route. Copy the Application (client) ID and the Directory (tenant) ID from the registration and use the issuer https://login.microsoftonline.com/<tenant-id>/v2.0. A tenant ID pasted from another directory leads to the same family of errors.

Full steps: Microsoft Entra ID SSO with SSOGEN, the SAML wizard guide and the OpenID Connect wizard guide. If sign-in gets further and then fails on the address, use the AADSTS50011 redirect URI checker.

Why Entra ID refuses apps it has no record of

Entra ID issues tokens only to applications it has an identity for in the tenant.

  • Application object. It describes how the service can issue tokens to the app.
  • Service principal. It defines what the app can do in this tenant, who can use it and which policies apply.

Without a service principal for the ID there is no policy to apply, so refusing is the safe default. The error means the app must be installed or consented to first.

What does AADSTS700016 mean?
Microsoft Entra ID could not find an application with the client ID in your request inside the tenant you sent it to. The usual reasons are a wrong ID, a request sent to the wrong tenant, or a multitenant app that no administrator or user in that tenant has installed or consented to.
How do I fix AADSTS700016?
Copy the identifier from the error, search for it under Entra ID, App registrations, and compare it with the client ID your app sends. Then confirm the tenant in the authority address. For a vendor app, an administrator must grant consent so an enterprise application exists in your tenant.
Why does AADSTS700016 say the application was not found in the directory?
The directory in the message is the tenant your request was addressed to, and it holds no application object or service principal with that ID. Either the ID is wrong, the tenant is wrong, or the app was never added there through registration or consent.
Can a client secret cause AADSTS700016?
Yes. If the value in the client ID setting is a secret instead of the Application (client) ID, the error quotes that string as the identifier. A real client ID is a GUID. Replace the value, then rotate the secret, because it now appears in logs and tickets.
What is the difference between AADSTS700016 and AADSTS50011?
AADSTS700016 is about the app: no application with that ID exists in the tenant. AADSTS50011 is about the address: the redirect URI sent does not match one registered for the app. Fix 700016 first, because a redirect URI check needs an app that is found.
How do I give admin consent so a multitenant app is added to my tenant?
An administrator opens Enterprise apps, selects the app, then Permissions and Grant admin consent. If the app is not in the tenant yet, they sign in at the admin consent address with the app’s client ID and the tenant ID or a verified domain.
Is it safe to paste my error message here?
The reader runs in your browser and sends nothing. The text can hold email addresses, tenant names and IDs, so paste only what you may look at. Treat any token or secret that appears in the text as exposed.

Where to go next

Sources

Sources, all read 2026-10-11: Microsoft Learn, Microsoft Entra authentication and authorization error codes (row AADSTS700016; no separate troubleshooting article for this code was found); OAuth 2.0 authorization code flow (Microsoft Learn); OAuth 2.0 and OpenID Connect protocols; How to register an app; Apps and service principals; How and why apps are added; Single and multitenant apps; Grant tenant-wide admin consent; Microsoft Q&A thread on this error. Microsoft and Entra are trademarks of their owner; SSOGEN is not affiliated with Microsoft.