OIDC Client Secret

Expanded Definition

An OIDC client secret is the confidential credential a relying party uses to authenticate to the OpenID Connect provider during token exchange, back-channel logout, or other confidential client interactions. In OpenID Connect Core 1.0, it is one mechanism for proving the application is the registered client it claims to be, but it is not a user credential and should not be treated like one.

In NHI security, the client secret sits in the same risk class as other long-lived secrets because compromise enables token theft, session hijacking, and impersonation of the application. Usage in the industry is still evolving around whether every confidential client must keep a static secret, or whether some deployments can shift to private key JWT, mTLS, or other stronger client authentication methods. NHI Management Group treats the core issue as governance: who can read the secret, where it is stored, how it is rotated, and how quickly it is revoked after exposure. The Guide to the Secret Sprawl Challenge shows why distributed storage is so often the real failure point, not the OAuth flow itself.

The most common misapplication is storing the OIDC client secret like a harmless configuration value, which occurs when developers place it in source control, build variables, or shared environment files.

Examples and Use Cases

Implementing OIDC client secrets rigorously often introduces lifecycle overhead, requiring organisations to weigh easier application onboarding against tighter rotation, vaulting, and incident-response discipline.

• A web application uses a client secret to redeem authorization codes with the identity provider, and the secret is stored in a secrets manager instead of the application repository.
• A CI/CD pipeline injects the secret at deployment time, reducing exposure in code but increasing the need for pipeline access controls and auditability, a pattern frequently discussed in the CI/CD pipeline exploitation case study.
• An engineering team rotates the secret after a suspected leak, then invalidates old values at the IdP to prevent continued token exchange with stolen credentials.
• A mobile or browser-based public client avoids client secrets entirely, because OpenID Connect treats public clients differently and they cannot keep a secret safely.
• A service integrates with a third-party IdP and uses a shorter-lived alternative, such as signed client assertions, where the platform supports stronger client authentication than static shared secrets.

For implementation guidance on adjacent controls, the OWASP Non-Human Identity Top 10 is useful for mapping secret handling to broader NHI risk patterns, while OpenID Connect client authentication guidance remains the baseline for protocol behavior.

Why It Matters in NHI Security

Client secret exposure turns an application into an impersonation target. Once stolen, an attacker can request tokens as that client, pivot into connected APIs, and bypass controls that assume the application is trusted. This is why NHI governance treats OIDC client secrets as high-value secrets, not simple configuration parameters. The risk is amplified because secrets are often copied into build systems, developer laptops, logs, and environment variables, then forgotten. NHI Mgmt Group reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes a static client secret especially exposed.

For governance, the practical controls are straightforward: limit which services can access the secret, rotate it on a defined schedule, prefer stronger client authentication where supported, and revoke immediately after any suspected disclosure. The reason this matters becomes obvious after an incident, not before. Organisations typically encounter unexpected token abuse only after a secret leak or pipeline compromise, at which point OIDC client secret management becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Secret
• How should security teams handle OIDC client secrets in production apps?
• What is the difference between client secrets and workload trust policies in OIDC?
• When should organisations choose private_key_jwt over a client secret?