Fix: AADSTS700016: Application with identifier was not found in the directory

If your sign in is failing with AADSTS700016 and the message Application with identifier was not found in the directory, Entra ID (Azure AD) is telling you that the client ID your app presented does not exist in the tenant it was sent to. The request never reaches the user or the credential check. Entra ID looks up the application by its identifier, finds nothing in that directory, and stops there.

What this error means

Every sign in sends a client_id (the Application (client) ID) to a specific tenant authority such as https://login.microsoftonline.com/{tenant}. Entra ID tries to match that identifier to an app registration or service principal in that tenant. AADSTS700016 means the match failed. The identifier and the directory it searched are both printed in the error text, which is your primary clue: read them before changing anything.

Common causes

• A wrong or mistyped Application (client) ID in configuration, environment variables, or a secret store.
• The request points at the wrong tenant: a single tenant app is being reached through /common, or through a tenant ID or domain where the app does not live.
• The app registration was deleted, or you are signed into the wrong Azure directory in the portal.
• A multi-tenant app that has never been consented to in the customer tenant, so no service principal exists there.
• Using the Object ID (of the registration or the service principal) where the Application (client) ID belongs.
• Copy and paste drift between environments, where dev and prod use different client IDs and one config was pointed at the wrong one.

How to fix it

Stabilize

1. Read the full error. Note the exact identifier in quotes and the directory (contoso.onmicrosoft.com or a tenant GUID). This tells you both what was sent and where it was searched.
2. If a deploy or config change immediately preceded the failure, roll back to the last known good configuration so users can sign in while you diagnose.

Diagnose

1. In the Entra portal, go to Microsoft Entra ID, App registrations, open your app, and read Overview. Compare the Application (client) ID and Directory (tenant) ID shown there against what your app sends.
2. Confirm you are in the correct directory. Use the Directories + subscriptions switcher in the portal top bar if you manage more than one tenant.
3. Confirm the authority your code uses. It should be https://login.microsoftonline.com/{tenant} where {tenant} is the tenant that actually owns the app, or organizations / common only if the app is genuinely multi-tenant.
4. Look the app up directly by client ID:

az login
az ad app show --id 11111111-1111-1111-1111-111111111111

If that returns the app, the registration exists. Then check whether a service principal exists in the target tenant:

az ad sp show --id 11111111-1111-1111-1111-111111111111

An error here, while az ad app show succeeds, points to a missing service principal (common for multi-tenant apps awaiting consent).

Fix

1. Correct the client ID and authority in config so they match the Overview page exactly. Make sure you copied the Application (client) ID, not the Object ID.

AZURE_CLIENT_ID=11111111-1111-1111-1111-111111111111
AZURE_TENANT_ID=22222222-2222-2222-2222-222222222222
AZURE_AUTHORITY=https://login.microsoftonline.com/22222222-2222-2222-2222-222222222222

2. For a single tenant app being reached through /common, change the authority to the specific tenant ID or the verified domain.
3. For a multi-tenant app, provision the service principal in the target tenant by having an administrator complete admin consent:

https://login.microsoftonline.com/{customer-tenant}/adminconsent?client_id=11111111-1111-1111-1111-111111111111

4. If the registration was deleted, recover it if it is still within the deleted items window, or recreate it and update the client ID everywhere it is referenced.

How to prevent it

• Store client IDs, tenant IDs, and authorities in config or a secret store, never hardcoded across the codebase.
• Document which client ID and tenant belong to each environment so config drift is easy to spot.
• Alert on sudden spikes in sign in failures so a bad deploy is caught in minutes, not by users.
• Always target the correct authority for the app type: a specific tenant for single tenant, organizations or common for multi-tenant.

When to call a senior engineer

If the client ID and authority both check out, the registration exists, and consent has been granted, but AADSTS700016 persists, the problem is usually subtler: replication lag after recreating an app, a conditional access or cross tenant access policy blocking provisioning, or two registrations with confusingly similar IDs across environments. If sign in is down in production and the cause is not obvious within your rollback window, bring in a senior engineer rather than trying config permutations against a live tenant.