A client secret is a credential used by an application to prove its identity to an identity provider during token exchange. In OIDC, it functions like a password for the workload, so exposure in code, logs, or build artifacts can enable impersonation and downstream access.
Expanded Definition
A client secret is the confidential half of a client credential pair used by a workload to authenticate to an identity provider during OAuth 2.0 or OIDC token exchange. Unlike a user password, it is not tied to a person; it is tied to an application, automation job, or service integration.
In NHI operations, the term covers more than a string stored in a config file. It includes the lifecycle around issuance, storage, retrieval, rotation, revocation, and auditability. Guidance varies across vendors on whether a client secret should be treated as a static secret, a bootstrap credential, or a transitional trust anchor before stronger patterns such as private_key_jwt, mTLS, or workload identity federation are introduced. The OWASP Non-Human Identity Top 10 frames this as a secret-management problem, while NIST-aligned identity guidance pushes practitioners toward stronger assurance and lower secret exposure over time.
The most common misapplication is assuming a client secret is safe because it is stored outside source code, which occurs when it is still exposed in logs, CI variables, deployment artifacts, or shared vault paths.
Examples and Use Cases
Implementing client secrets rigorously often introduces operational friction, because every secure storage and rotation step can slow down release automation and integration troubleshooting, requiring organisations to weigh resilience against convenience.
- A web application uses a client secret to request an access token from an OpenID Provider, but the secret is injected at deploy time and never written to the repository.
- A CI/CD job retrieves a client secret from a secrets manager before calling a SaaS API, reducing the chance of exposure in build logs. The pattern is closely related to the leakage scenarios described in the Guide to the Secret Sprawl Challenge.
- An engineering team replaces a long-lived client secret with workload identity federation after reviewing the risks highlighted in the Shai Hulud npm malware campaign, where exposed secrets became immediate abuse paths.
- A service integration still requires a client secret for backward compatibility, but the organisation rotates it automatically and scopes access narrowly under RBAC.
- A platform team uses the Reviewdog GitHub Action supply chain attack as a reminder that secrets embedded in developer tooling can be harvested at scale.
Where available, stronger identity patterns such as federation and short-lived credentials should replace static client secrets, especially for high-value integrations described in SPIFFE and related workload identity models.
Why It Matters in NHI Security
Client secrets matter because they are often the easiest credential for attackers to find and the hardest for teams to inventory. NHI Mgmt Group research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes client secrets a frequent starting point for lateral movement and API abuse. The risk is amplified when teams confuse authentication with authorization and assume that a valid token exchange proves the integration is trustworthy.
Practitioners should treat client secrets as temporary risk, not permanent architecture. That means limiting scope, enforcing rotation, monitoring for leakage, and replacing secrets with stronger workload identity patterns whenever possible. The CI/CD pipeline exploitation case study and the 230M AWS environment compromise both show how one exposed secret can become a broad operational foothold. For a broader defensive lens, the 52 NHI Breaches Analysis reinforces that secret exposure is rarely isolated.
Organisations typically encounter client-secret risk only after a token has been abused, at which point the credential becomes operationally unavoidable to revoke, rotate, and investigate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret management failures, including exposed client secrets and poor rotation. |
| NIST SP 800-63 | AAL2 | Helps frame assurance expectations for credentials used in machine authentication flows. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous validation and minimizes reliance on long-lived shared secrets. |
Inventory client secrets, restrict exposure, and rotate or replace them before they become standing access.
