AADSTS50012 - Invalid Client Secret or Assertion
Azure AADSTS50012 is a client-authentication failure indicating that the supplied client secret, certificate, or JWT assertion is invalid, expired, or does not match the application registration in Microsoft Entra ID.
Last reviewed: April 10, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Invalid Client Secret or Assertion Mean?
AADSTS50012 is a proof-of-possession failure. In non-interactive flows, the application must authenticate itself to Entra ID. If you provide a secret, it must be the literal value and not the secret ID. If you provide a certificate, the thumbprint must match a public key already uploaded to the app registration. If you provide a JWT assertion, it must be signed correctly and contain the expected claims. If any of these proofs fail validation, Entra ID denies the token request immediately.
Common Causes
- -Secret ID Instead Of Secret Value: The application uses the GUID-style secret ID instead of the actual secret value shown when the secret was created.
- -Expired Credentials: The client secret or certificate is past its expiration date.
- -Thumbprint Mismatch: The private key used to sign a client assertion does not match the public certificate uploaded to the app registration.
- -Assertion JWT Malformation: A custom-built JWT assertion contains the wrong
aud,iss,sub, signing key reference, or expiration window. - -Environment Desync: The application is using a client ID from one environment and a secret or certificate from another.
How to Fix Invalid Client Secret or Assertion
- 1Regenerate The Secret If Needed: If there is any uncertainty, create a new client secret in the portal and update runtime configuration immediately.
- 2Verify Secret Value vs Secret ID: Ensure the app uses the actual secret value from Certificates & Secrets, not the secret identifier.
- 3Check Certificate Expiry And Upload State: Confirm the certificate is still valid and its public key exists on the correct app registration.
- 4Prefer Managed Identities: If the code runs on an Azure-hosted service, switch to Managed Identity to avoid manual secret and certificate handling altogether.
Step-by-Step Diagnosis for Invalid Client Secret or Assertion
- 1Open Microsoft Entra admin center and go to App Registrations > Certificates & Secrets for the target app.
- 2Confirm which active secrets or certificates exist and whether any have expired.
- 3Check application startup logs or runtime config to verify the exact
client_idandtenant_idin use. - 4If using a JWT assertion, decode it with a tool such as
jwt.msand verifyiss,sub,aud,exp, and key identifiers likekidorx5t.
Secret vs Certificate Logic
- -Secrets: Simpler to implement, but most AADSTS50012 failures come from expiry or the common Secret ID vs Secret Value confusion.
- -Certificates: More secure, but failures usually come from signing-key mismatch, expired certs, or assertion construction errors.
Common JWT Assertion Claims
- -iss (Issuer): Must be the client ID of the app.
- -sub (Subject): Must be the client ID of the app.
- -aud (Audience): Must match the correct Entra token endpoint for the tenant.
Implementation Examples
const msalConfig = {
auth: {
clientId: "YOUR_CLIENT_ID",
authority: "https://login.microsoftonline.com/YOUR_TENANT_ID",
clientSecret: "YOUR_ACTUAL_SECRET_VALUE", // NOT the Secret ID
}
};curl -X POST "https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token" \
-d "client_id={client-id}" \
-d "scope=https://graph.microsoft.com/.default" \
-d "client_secret={secret-value}" \
-d "grant_type=client_credentials"Seen in Production
Secret ID copied into runtime config by mistake
Frequency: high
Example: A production secret is rotated, but the operator pastes the Secret ID GUID into the environment variable instead of the secret value. The confidential client immediately fails with AADSTS50012.
Fix: Replace the Secret ID with the actual secret value and redeploy the affected runtime.
Certificate expires and background worker loses access
Frequency: common
Example: A background worker uses certificate-based auth. The certificate expires over the weekend, and token acquisition begins failing with AADSTS50012.
Fix: Upload the renewed public certificate to Entra and update the worker to use the matching private key.
Debugging Tools
- -Entra ID Portal Certificates & Secrets View: Best place to verify active keys and expiration state.
- -Jwt.ms: Useful for decoding and validating custom-built client assertions.
- -Azure Key Vault Logs: Helpful for verifying whether the app is actually pulling the latest secret or certificate reference at runtime.
How to Verify the Fix
- -Confirm the application can successfully exchange its client credential for an access token.
- -Check sign-in logs in Entra ID and verify the service principal status transitions from Failure to Success.
- -Ensure the new secret or certificate has been propagated to every deployment slot, worker, or container that uses it.
How to Prevent Recurrence
- -Use Key Vault Integration: Store secrets in Azure Key Vault and reference them directly instead of hardcoding or manually copying them.
- -Enable Expiry Monitoring: Alert before secrets or certificates expire so rotation happens on schedule.
- -Use Infrastructure As Code: Manage app registrations and credentials declaratively to keep client IDs and credentials aligned across environments.
- -Pro tip: When copying a new secret from the portal, grab it immediately and store it securely. Once the blade closes, teams often come back later and mistakenly copy the Secret ID instead of the original secret value.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.