Client secret

Understand the concept

In plain English

A client secret is a credential an application uses with its client ID to prove its identity to Microsoft Entra ID. Think of it as an app password, not a user password. It is only shown when created, must be stored securely, and eventually expires. Scripts, web apps, and background services sometimes use client secrets to request tokens without a signed-in user. They are easy to create but easy to mishandle. In many production designs, certificates, managed identities, or federated credentials are safer long-term choices.

Why it matters

Client secrets matter because they are one of the most common weak points in cloud identity. A leaked secret can let an attacker request tokens as the application until the secret expires or is revoked. An expired secret can break production apps, pipelines, integrations, and background jobs instantly. Because secrets are simple, teams often create them for quick fixes and then forget ownership, expiration, and storage rules. Good secret management prevents outages and reduces breach impact. Operators need to know which workloads use each secret, where it is stored, when it expires, who can rotate it, and what safer credential pattern could replace it.

Technical context

Client secrets live on Microsoft Entra app registrations under credentials. A confidential client sends the client ID, tenant authority, and secret to the token endpoint during OAuth client credential or authorization code flows that require application authentication. The secret validates the application, while API permissions, app roles, service principal state, and RBAC decide what access the resulting token can use. Secrets appear in app settings, Key Vault references, pipeline variables, or external secret stores. Azure only returns the secret value at creation time, so rotation must be planned.

Exam context

Compare with

Where it is used

Where you see it

1. In Microsoft Entra app registrations, Certificates and secrets shows client secret names, creation dates, expiration dates, and the one-time value after creation, rotation, and expiry warnings.
2. In App Service settings, pipeline variables, Key Vault secrets, and external vaults, client secrets appear as protected configuration used for token acquisition by workloads and jobs.
3. In sign-in logs and application telemetry, expired or invalid client secrets appear as token failures, authentication errors, retries, and sudden integration outages during rotations and deployments.

Common situations

• Authenticate a legacy confidential application that cannot yet use managed identity, certificates, or workload identity federation.
• Rotate an expiring application credential without downtime by adding a new secret before removing the old one.
• Move secrets out of source code and pipeline logs into Key Vault or another managed secret store.
• Audit app registrations for unknown owners, long-lived credentials, stale secrets, and excessive application permissions.
• Respond to a suspected leak by revoking the credential, validating dependent workloads, and reviewing token activity.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Azure CLI

With ten years of Azure engineering behind me, I use Azure CLI for client secret work because rotations and audits need precision. The CLI can list app credentials, show expiry dates, add a replacement secret, and identify owners without relying on a portal page that someone screenshots into a ticket. It also supports safe automation patterns where a new value is written directly into Key Vault or a deployment secret store. During incidents, CLI output helps identify whether an outage is caused by expiration, wrong tenant, disabled service principal, or a deployment that still references the old secret. Repeatable commands make emergency rotation less chaotic.

az ad app credential list --id <client-id>

az ad app credential reset --id <client-id> --display-name <name> --end-date <yyyy-mm-dd>

az ad app credential delete --id <client-id> --key-id <key-id>

az keyvault secret set --vault-name <vault> --name <secret-name> --value <secret-value>

Architecture context

Architecturally, a client secret is a credential for a confidential workload, and it should be treated as temporary risk. It belongs behind a controlled secret boundary such as Key Vault, managed pipeline variables, or an approved external vault. The application architecture should avoid storing it in source code, container images, local files, or plain app settings when a Key Vault reference or managed identity is possible. Production systems need dual-secret rotation windows, owner alerts, expiry tracking, and rollback steps. New Azure-native workloads should evaluate managed identity or workload identity federation first, using client secrets mainly for legacy integrations or platforms without stronger trust options.

Security

Security impact is direct and high. A client secret is bearer-style proof for the application, so anyone who obtains it can attempt to get tokens as that app. Store secrets in Key Vault or another managed vault, restrict who can read and write them, and avoid printing them in logs, pipeline output, crash dumps, or support tickets. Set short expirations with alerting, rotate before expiry, and remove unused credentials. Prefer certificates, managed identities, or federated credentials when feasible. Review app permissions because the damage from a leaked secret depends on what the application can access after token issuance in production systems.

Cost

A client secret has no direct meter, but poor management creates outage, audit, and engineering cost. Expired secrets can halt paid compute while jobs retry and teams troubleshoot the wrong layer. Leaked secrets can trigger incident response, access reviews, forensics, customer notifications, and emergency rotations. Too many unmanaged secrets increase audit time and make app-registration cleanup risky. Stronger patterns such as managed identity or workload identity federation may reduce long-term operational cost even if migration takes effort. FinOps and governance reviews should treat secret sprawl as toil: duplicated credentials, unknown owners, excessive expirations, and manual rotations all consume expensive engineering time.

Reliability

Reliability risk comes from expiration, unsynchronized rotation, secret-store outages, and configuration drift. If a secret expires, applications may fail to acquire tokens even though compute, network, and APIs are healthy. If rotation updates Key Vault but not app configuration, one instance may work while another fails. Reliable designs use overlapping secrets, staged rollout, health checks that include token acquisition, and alerts well before expiry. Document every dependent service, pipeline, and external integration before deleting an old secret. Test rollback because restoring the old value may be impossible if it was not stored securely after creation and rotation records during emergencies.

Performance

Performance impact is usually indirect. A valid client secret does not make an API faster, but bad secret handling can slow startup, token acquisition, and recovery. Applications may repeatedly retry token requests with an expired or wrong secret, causing delayed background jobs and noisy logs. Secret retrieval from a vault adds a small dependency that should be cached responsibly and monitored. Rotation can temporarily affect performance if instances reload configuration unevenly or token caches are flushed during peak traffic. Performance reviews should watch authentication latency, token failure rates, retry storms, and whether secret lookup paths block request processing under load.

Operations

Operators manage client secrets through inventory, expiry alerts, rotation runbooks, incident response, and access reviews. Practical tasks include listing credentials, finding owners, adding a new secret, updating Key Vault or pipeline variables, restarting dependent apps, and removing old credentials after validation. Runbooks should specify where the value is stored, how to avoid exposing it, how long overlap lasts, and how to verify token acquisition. During incidents, operators should check sign-in logs, app credential expiry, recent changes, and whether a workload is still reading cached configuration. Every rotation should produce evidence without recording the secret value in reports, tickets, or logs.

Common mistakes

• Deleting the old secret immediately after creating a new one before all app instances and pipelines have reloaded configuration.
• Storing a client secret in source control, container images, deployment logs, or unprotected application settings.
• Rotating the secret but forgetting external partners, scheduled jobs, or disaster recovery slots that still use the old value.