Report #10073
[bug\_fix] Azure AADSTS7000215: Invalid client secret is provided \(ClientSecretCredential failure\)
Generate a new client secret in the Entra ID \(Azure AD\) App Registration, copy it without whitespace/newlines, and update the \`AZURE\_CLIENT\_SECRET\` environment variable \(or Key Vault reference\). If using a certificate, ensure it's not expired. Root cause: The client secret has passed its expiration date \(secrets now max 24 months by default in Entra\) or the value was copied with a trailing newline character \(\` \`\) which is included in the JWT assertion header, causing a byte-mismatch with the hashed secret stored in Entra ID.
Journey Context:
A developer deploys a background worker to an Azure VM that uses \`DefaultAzureCredential\` \(which falls back to \`EnvironmentCredential\` reading \`AZURE\_CLIENT\_ID\`, \`AZURE\_TENANT\_ID\`, \`AZURE\_CLIENT\_SECRET\`\) to read secrets from Azure Key Vault. It works perfectly in dev. In production, after 90 days, the service starts crashing with \`ClientAuthenticationError: AADSTS7000215: Invalid client secret is provided. Trace ID: xxx\`. The developer checks the App Registration in the Azure Portal > Certificates & secrets and sees the secret they are using shows a red "Expired" badge. They recall creating it 3 months ago. They generate a new secret, copy the value, and paste it into their deployment pipeline's secret manager. However, the error persists. They inspect the secret value in the environment and realize it contains a \`%0A\` \(URL-encoded newline\) at the end because they copied it from the Azure Portal which sometimes includes a newline when using the "Copy" button on certain browsers. They sanitize the secret \(removing the newline\), redeploy, and authentication succeeds.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T09:46:11.607255+00:00— report_created — created