Entra ID AADSTS7000215: Invalid Client Secret Provided

When an application authenticates to Microsoft Entra IDThe KBY LexiconMicrosoft Entra IDA concise technical definition of Microsoft Entra ID: what it is, how it fits identity architecture, and where engineers must validate before change. Read Full Context as itself, it often does so as a confidential client: it presents a client ID to say who it is and a client secret to prove it. If the proof does not match what the identity platform holds, the token request fails with error AADSTS7000215, reported as an invalid client secret provided. The message is accurate but brief, and it tempts people to regenerate credentials at random.

This guide builds the mental model first, then works through a diagnosis. The most common trap is the difference between a secret’s value and its secret ID, two strings that sit side by side in an app registration and look equally credential-like. You will learn to tell them apart, find or replace the correct value, update the app and confirm that token requests succeed, all in a bounded lab before any production change.

#Learning Objectives

• Explain what a client secret proves in a confidential client token request.
• Distinguish a secret value from its secret ID.
• Diagnose the error by separating wrong-value, expired, wrong-app and wrong-tenant causes.
• Create and deploy a replacement secret in a lab with a stop condition and rollback.
• Confirm token requests succeed and describe production permissions and escalation.

#Prerequisites

• An isolated or non-production validation environment, such as a test tenant or a test app registration that no live service depends on.
• Confirmation of product version and your permissions before applying any change. Entra portal layouts and options change, so check the current Microsoft Entra ID documentation for the screens and wording you see.
• Working knowledge of OAuth 2.0The KBY LexiconOAuth 2.0OAuth 2.0 is an authorization framework, not an authentication protocol — here is its precise operational definition, roles, token flow and common failure mode. Read Full Context client credentials: a client calls the token endpoint with its own credentials and receives an access token.
• A protected place to keep secrets. Do not paste secret values into tickets, chat, screenshots or source control.

#Content

#

The mental model: who proves what to whom

An app registration is the definition of an application inside a tenant. It has an application (client) ID, which is public-ish identity information, and may have credentials attached. A client secret is one such credential: a long random string that only the registration owner and the running application should know. When the app requests a token, Entra ID looks up the registration identified by the client ID, in the tenant named in the token endpoint address, and checks the presented secret against its stored credentials. The service stores a verifiable form of the secret rather than letting you read it back, which is why a lost value usually cannot be retrieved.

That gives three trust boundaries. The app and its configuration store hold the secret. The network path carries it to the token endpoint over TLS. Entra ID decides whether it matches. AADSTS7000215 means the decision at the third boundary was no, so the fault lies in what the first boundary supplied or in what the registration currently holds.

#

Secret value versus secret ID

When you add a client secret in an app registration, the portal lists a description, an expiry date, a value and a secret ID. The secret ID is a GUID that identifies that credential entry, much like a row identifier. It is not the credential. The value is the credential. Microsoft documents that the value is displayed when the secret is created, so you must record it then; later views of the registration show the ID but not the value. Confirm this behaviour against the current documentation, because portal behaviour is version-sensitive.

Copying the ID into the app’s secret setting is a very common cause of this specific error, because both strings are visible in the same row and the ID is the one that remains visible afterwards.

#

Diagnosis flow

The diagram orders checks from cheapest and most common to most involved. Each branch ends in a retest, because a fix is only a hypothesis until a token request succeeds.

#

Why each step exists

Comparing the configured string with the portal row costs nothing and rules out the ID mix-up. Checking client ID and tenant matters because a correct secret presented for the wrong registration is still invalid. Checking expiry matters because secrets have a lifetime, and an expired entry no longer authenticates. For a related expiry scenario, see rotating expired app client secrets safely. Checking for truncation or stray whitespace matters because configuration systems, shell quoting and copy-paste can silently alter long strings.

#

Production bridge

In production, creating a secret requires rights over the app registration, typically ownership of it or a directory role that permits managing applications. Grant the narrowest role that works; do not use a Global Administrator account for routine secret work. Prefer a vault for storing the value, limit who can read it, and set the shortest expiry the operating team can sustainably rotate. Add the new secret alongside the old one so the service never has a gap, then remove the old one only after validation. Where the platform supports it, a managed identity or certificate credential removes the shared-string problem altogether; check current documentation for what your workload supports. Escalate to the application owner if you do not own the registration, and to the identity or security team if you suspect the secret was exposed, since an exposed secret should be replaced and the old one removed promptly. Related sign-in failures with different causes are covered in AADSTS65001 and AADSTS50011. For privileged access hygiene around who can edit registrations, see just-in-time admin access with PIM.

#Examples

#

Worked example: the secret ID in the secret setting

Input. A lab service uses a client credentials request. Its configuration holds a client ID and a secret setting. The secret setting contains a GUID. The portal row for the registration’s only secret shows the same GUID in the secret ID column and a different, masked or absent value.

Output. The token endpoint returns an error response containing AADSTS7000215 and no access token.

Interpretation. The app presented an identifier where a credential was expected. Entra ID cannot match a GUID that is not the secret value, so it rejects the proof. Nothing is wrong with the tenant or the registration. The correction is to supply a real secret value. Because the original value was not recorded, the practical route is to create a new secret, copy its value once into the protected store, and point the app at it.

#

Worked example: right value, wrong registration

Input. The secret setting holds a genuine value, but the client ID belongs to a second, similarly named registration in the same tenant.

Output. The same error.

Interpretation. The secret is valid for one registration but was presented for another. This is why the diagnosis flow checks the client ID before creating anything new. Creating a secret on the wrong registration would add credentials without fixing the fault.

#Exercises

#

Exercise: replace a secret in a lab registration

Objective. Reproduce AADSTS7000215 safely, then fix it and confirm success.

Setup. In a non-production tenant, use a test app registration that no live service uses and that you own. Use a test client that can send a client credentials request, such as a small script or API tool. Keep the secret value in a protected store only, never in the exercise notes.

1. Reproduce: configure the test client with the registration’s client ID and the secret ID as the secret. Send a token request. Expected evidence: an error response naming AADSTS7000215 and no access token.
2. Explain: write one sentence saying why the ID is not the credential. This forces the model, not the clicks, to drive the fix.
3. Create: in the registration’s certificates and secrets area, add a new client secret with a short description and a short expiry. Copy the value immediately into the protected store. Leave any existing secret in place.
4. Update: replace the client’s secret setting with the new value, confirming the client ID and tenant are those of this registration.
5. Retest: send the token request again. Expected evidence: a response containing an access token, with the expected audience and no error.

Pass condition. Step 1 fails with the named error, and step 5 returns a token without error.

Stop conditions. Stop if the registration is used by any live service, if you cannot confirm ownership, if the error code differs from AADSTS7000215 (diagnose that code instead), or if the secret value appears anywhere other than the protected store.

Cleanup and rollback. Delete the lab secret and the test client’s configuration once finished. If a replacement fails, the previous setting can be restored because the old secret entry was not removed. Delete a superseded secret only after step 5 passes.

#Validation Guidance

Validate by outcome, not by the absence of complaints. A successful token request is the primary evidence. Inspect the returned token’s claims, using a trusted local tool rather than a public decoder, and confirm the application ID and tenant match your registration. Then confirm the calling application works end to end for one real operation, because a token alone does not prove the downstream resource accepts it. After removing the old secret, repeat the request to prove nothing still depends on it. Also check sign-in logs for the registration for successful service principal sign-ins; log names and locations vary by licence and version, so confirm them in current documentation. Record the secret’s expiry date in your rotation calendar, since a successful fix today leads to the same outage later if expiry is untracked.

#Common Mistakes

• Symptom: error persists after copying from the portal. Cause: the secret ID was copied. Diagnosis: compare the string with the ID column. Correction and recovery: create a new secret and store its value; keep the old entry until retest passes.
• Symptom: error after a secret was created yesterday. Cause: the app registration, tenant or client ID differs from where the secret was created. Diagnosis: compare IDs. Correction: fix the configuration and retest.
• Symptom: a previously working service now fails. Cause: expiry or deletion of the secret. Correction: add a new secret, update the app, then retire the old one. Escalate to the owner if deletion was unplanned.
• Symptom: value looks right but fails. Cause: whitespace, truncation or quoting altered the string in the configuration system. Correction: re-enter the value from the store and check how the platform handles special characters.
• Symptom: secrets appear in tickets or chat. Cause: debugging by sharing. Response: treat as exposed, replace it and remove the old one.

#Key Takeaways

• The secret value is the credential, while the secret ID only labels the entry.
• Check value, client ID, tenant and expiry before creating a new secret.
• Add the new secret beside the old one, validate with a real token request, then remove the old entry.

Before closing a change, confirm that a fresh token request succeeds using the stored value, that the old secret is removed only after that passes, that the new expiry date is in the rotation calendar, and that no secret value appears in tickets or logs. If the new secret fails, restore the previous setting while the old entry still exists, and escalate to the registration owner or security team if you cannot explain the failure.