App sign-in errors in Microsoft Entra ID: AADSTS7000215, AADSTS700016, AADSTS50011 and more

When a script, connector or web app can't get a token from Microsoft Entra ID, the error rarely reaches a user. It sits in a log file, a pipeline run or an API response, and the integration quietly stops working. In this post I'll go through six app-side AADSTS errors: what each one means, where to find the failed sign-in, and how to fix and test it.

Symptoms#

A scheduled script, connector, pipeline or line-of-business web app fails to authenticate. Non-interactive apps get a JSON response from the token endpoint with error, error_description, error_codes and a correlation_id; interactive apps show the code on the sign-in page. The messages:

AADSTS7000215: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID, for a secret added to app '...'.
AADSTS7000222: The provided client secret keys for app '...' are expired.
AADSTS700016: Application with identifier '...' was not found in the directory '...'.
AADSTS50011: The redirect URI '...' specified in the request does not match the redirect URIs configured for the application '...'.
AADSTS700027: Client assertion failed signature validation.
AADSTS500011: The resource principal named ... was not found in the tenant named ...

Why it happens#

Every app has two objects. The app registration (application object) lives in its home tenant and holds the credentials and redirect URIs. The enterprise app (service principal) is the app's identity in each tenant where it's used. A token request names a tenant, a client ID, a credential and a resource, and each of these errors means one of them didn't line up.

How to fix it#

1. Find the failed sign-in#

In the Microsoft Entra admin center, go to Entra ID › Monitoring & health › Sign-in logs. App-only sign-ins are on the Service principal sign-ins tab; apps that sign users in appear under the user sign-in tabs. Filter by the application ID and status Failure, or search for the correlation ID from the error. The details show the error code, failure reason, resource and client credential type. If the app doesn't exist in the tenant (700016), there may be no service principal entry, so use the correlation ID and the timestamp instead.

2. AADSTS7000215 and AADSTS7000222: replace the secret properly#

1. Open Entra ID › App registrations, select the app and open Certificates & secrets › Client secrets. Check the expiry dates.
2. Select New client secret and copy the Value straight away; it's only shown once. The Secret ID column is an identifier, not the secret.
3. Update every place the app reads the secret from: its configuration, the vault, pipeline variables, or a local override left over from development.
4. Delete the old secret only after the new one works.

Connect-MgGraph -Scopes "Application.Read.All"
$app = Get-MgApplication -Filter "appId eq '11111111-2222-3333-4444-555555555555'"
$app.PasswordCredentials | Select-Object DisplayName, KeyId, EndDateTime
$app.KeyCredentials | Select-Object DisplayName, KeyId, EndDateTime

3. AADSTS700016: confirm the app exists in the right tenant#

• Compare the client ID in the request with Application (client) ID on the app's Overview page.
• Check the tenant in the authority URL (login.microsoftonline.com/<tenant>/). A single-tenant app only exists in its home tenant.
• Check for a service principal: Get-MgServicePrincipal -Filter "appId eq '...'". If a third-party or multitenant app has none, an admin needs to add it by granting consent (see AADSTS65001 and AADSTS90094 consent errors).
• For SAML apps, compare the issuer the app sends with Identifier (Entity ID) under Entra ID › Enterprise apps › app › Single sign-on › Basic SAML Configuration.

4. AADSTS50011: register the exact redirect URI#

Copy the redirect URI and app ID from the error. Open the app registration, select Authentication, add the URI to the platform configuration the app uses, save, and allow a few minutes before retrying. If the URI in the request is wrong, for example http:// from an app behind a TLS-offloading proxy, fix the app's configuration instead of registering a bad URI. For SAML apps, the value to check is the Reply URL in Basic SAML Configuration.

5. AADSTS700027: fix the certificate credential#

Under Certificates & secrets › Certificates, upload the public key (.cer, .pem or .crt) of the certificate the app actually signs with, then compare thumbprints with the client's store:

Get-ChildItem Cert:\LocalMachine\My, Cert:\CurrentUser\My |
    Select-Object Subject, Thumbprint, NotAfter

6. AADSTS500011: fix the resource#

Check the scope or resource value the app requests, such as https://graph.microsoft.com/.default or a custom API's App ID URI. Confirm the API has a service principal in the tenant with Get-MgServicePrincipal -Filter "appId eq '...'" using the API's app ID. For a partner's multitenant API, add and consent to the API first.

Verify the fix#

For app-only access, request a token directly. A good result returns token_type Bearer and an expires_in value, and a Success entry appears on the Service principal sign-ins tab. Don't print or store the token itself.

$tenantId = "contoso.onmicrosoft.com"
$body = @{
    client_id     = "11111111-2222-3333-4444-555555555555"
    client_secret = $secretValue   # read from your vault, never hard-coded
    scope         = "https://graph.microsoft.com/.default"
    grant_type    = "client_credentials"
}
$response = Invoke-RestMethod -Method Post -Body $body `
    -Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token"
$response.token_type; $response.expires_in

For certificate-based apps, Connect-MgGraph -ClientId ... -TenantId ... -CertificateThumbprint ... is a quick test. For interactive apps, sign in once and confirm the user sign-in entry for the app shows Success.

Prevent it next time#

• Track secret and certificate expiry and give every app an owner; App registrations and service principals: secrets, consent and over-privileged apps has the reporting script.
• Prefer certificates, managed identities or workload identity federation over client secrets, and keep any secret in a vault rather than in config files.
• Register redirect URIs for every environment (development, test, production) as part of the deployment, not after the first failure.
• Log the correlation ID with every error; see Reading Microsoft Entra sign-in logs like an engineer and the AADSTS error codes quick reference.

References#

• Microsoft Entra authentication and authorization error codes
• Error AADSTS50011: the redirect URI does not match the redirect URIs configured for the application
• How to troubleshoot Microsoft Entra sign-in errors