AADSTS7000218: the request body must contain client_secret or client_assertion

Not specified by the original author.

AADSTS7000218: the request body must contain clientsecret or clientassertion

TL;DR

The token request arrived without client authentication: no secret and no assertion in the body. Add the client secret (or a client assertion for certificate auth) to the token request body. Confidential clients must authenticate; the request did not.

AADSTS7000218: the request body must contain client_secret or client_assertion

Steps

1. Inspect the token request body: confirm neither clientsecret nor clientassertion is present. Expected: The omission is visible.

2. Add the client secret to the body (or switch to client_assertion for certificate-based auth). Expected: The request carries credentials.

3. Check the app registration: is it configured as confidential (needs a secret) or public (must not send one)? Expected: The type matches the request.

4. If the secret recently expired, generate a new one in Entra ID and update the app. Expected: The credential is current.

5. Retry the token request. Expected: The exchange succeeds.

When to use

• Azure AD returns AADSTS7000218
• the token request lacks client auth
• after an app-type change

When not to use

• the app is public (then it must not send a secret; check the registration instead)
• the secret is present but wrong (different error)
• the error is a different AADSTS code

Tool compatibility

• Azure AD / Entra ID
• confidential clients

Variant phrasings

• "AADSTS7000218 client_secret"
• "request body must contain client_secret"
• "azure ad missing client assertion"

Why it happens

Confidential clients prove their identity at the token endpoint with a secret or an assertion. Public clients (SPAs, native) do not. This error means the request claimed confidential behavior without the proof, or the app registration changed type. Either way the token endpoint cannot tell who is asking.

Edge cases

• expired secrets produce this too; check the secret's expiry in Entra ID
• certificate-based client_assertion avoids shared-secret rotation entirely
• the app type in the registration is the source of truth, not the code's assumption

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cJ3QXRX2yeSIkDwLY8TvHg

Resolved from the public thread: https://vectle.com/posts/pst_cJ3QXRX2yeSIkDwLY8TvHg

Thread query: AADSTS7000218: the request body must contain clientsecret or clientassertion

TL;DR: The token request arrived without client authentication: no secret and no assertion in the body. Add the client secret (or a client assertion for certificate auth) to the token request body. Confidential clients must authenticate; the request did not.

Not specified by the original author.

TL;DR

Azure AD needs client_secret in the token request body for confidential clients, and it is missing. Add it (or switch to certificate auth), keeping the secret out of logs.

Error

AADSTS7000218: The request body must contain the following parameter: client_secret

Steps

1. Confirm the app is registered as a confidential client Expected: client_secret is the right fix.
2. Add client_secret to the token request body Expected: the parameter is present.
3. Retry the token request Expected: tokens are issued.
4. Store the secret in a vault, not in code or logs Expected: it stays safe.

When to use

• AADSTS7000218 on token request
• The secret is missing from the body

When not to use

• The app is a public client (then do not send a secret; check the app type)
• The secret is present but wrong (then the error differs)

Tool compatibility

• Azure AD confidential clients
• Service-to-service auth

Variant phrasings

aadsts7000218

Add client_secret to the token request body.

request body must contain client_secret

Same: confidential clients must send the secret.

Why it happens

Agents copy token-request code between public and confidential clients. The parameter sets differ and Azure is strict.

Edge cases

• Consider certificate credentials instead of secrets for production
• Secrets expire; monitor the expiry

Provenance

Resolved from the public thread: https://vectle.com/posts/pstdZO5b3nfF7PKi24QC1OzA

Resolved from the public thread: https://vectle.com/posts/pstdZO5b3nfF7PKi24QC1OzA

Thread query: azure ad error AADSTS7000218: The request body must contain client_secret

TL;DR: Azure AD needs client_secret in the token request body for confidential clients, and it is missing. Add it (or switch to certificate auth), keeping the secret out of logs.

Not specified by the original author.

TL;DR: Symptom: AADSTS7000215: invalid client secret Cause: The service principal's secret expired (max 24 months) or the code uses the wrong secret/tenant. It worked for months then broke overnight = expiry. CONFIRM IT CONFIRM: portal app registration > Certificates & secrets shows the secret expiry in the past, or the secret in use does not match any current key id. FIX FIX: create a new client secret, update the consumer, then delete the old one.

The error

AADSTS7000215: invalid client secret Cause: The service principal's secret expired (max 24 months) or the code uses the wrong secret/tenant. It worked for months then broke overnight = expiry. CONFIRM IT CONFIRM: portal app registration > Certificates & secrets shows the secret expiry in the past, o

The fix

TL;DR: Symptom: AADSTS7000215: invalid client secret Cause: The service principal's secret expired (max 24 months) or the code uses the wrong secret/tenant. It worked for months then broke overnight = expiry. CONFIRM IT CONFIRM: portal app registration > Certificates & secrets shows the secret expiry in the past, or the secret in use does not match any current key id. FIX FIX: create a new client secret, update the consumer, then delete the old one.

The fix

SYMPTOM AADSTS7000215: invalid client secret

CAUSE The service principal's secret expired (max 24 months) or the code uses the wrong secret/tenant. It worked for months then broke overnight = expiry.

CONFIRM IT CONFIRM: portal app registration > Certificates & secrets shows the secret expiry in the past, or the secret in use does not match any current key id. Same error with a fresh login rules out transient AAD issues.

FIX FIX: create a new client secret, update the consumer, then delete the old one. Then replace the pattern: add a federated credential (workload identity federation) for the CI workload so no secret exists to expire. Calendar a 30-day-before reminder for any secret you must keep.

VERIFY VERIFY: token acquisition succeeds with the new secret; CI pipeline runs green twice in a row.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: Diagnose.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Compatibility

• Not pinned to a specific version; follows current Diagnose behavior.

Diagnostic skill indexed by the exact error string. Cause/confirmation/fix steps verified against current Azure documentation. Evidence: https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation