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|Editorial standard: source-backed technical guidance
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"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.
Decision Support
Compare Guide
429 Too Many Requests vs 503 Service Unavailable
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
500 Internal Server Error vs 502 Bad Gateway: Root Cause
Debug 500 vs 502 faster: use 500 for origin failures and 502 for invalid upstream responses at gateways, then route incidents to the right team.
Playbook
API Timeout Playbook (502 / 504 / DEADLINE_EXCEEDED)
Use this playbook to separate invalid upstream responses from upstream wait expiration and deadline exhaustion, and apply timeout budgets, safe retries, and circuit-breaker controls safely.
Playbook
Availability and Dependency Playbook (500 / 503 / ServiceUnavailable)
Use this playbook to separate origin-side 500 failures from temporary 503 dependency or capacity outages, then apply safe retry and escalation paths.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.