How should security teams handle OIDC client secrets in production apps?

Why This Matters for Security Teams

OIDC client secrets are often treated like harmless app settings, but in production they function as bearer credentials that can mint trust. If a secret is copied into a build log, shared repo, container image, or ticketing system, an attacker can impersonate the application and access downstream APIs, identity providers, or partner systems. That is why NHI governance treats client secrets as privileged credentials, not convenience data.

This matters even more because secrets rarely stay where teams intend them to stay. GitGuardian reported 28.65 million new hardcoded secrets in public GitHub commits in 2025, a 34% year-over-year increase, which shows how quickly small handling mistakes become large-scale exposure. NHIMG research on Guide to the Secret Sprawl Challenge and the Reviewdog GitHub Action supply chain attack both show how quickly CI/CD systems can turn a single secret into broad compromise. The practical lesson is that storage location, access scope, and revocation speed matter as much as the secret itself. In practice, many security teams discover OIDC secret leakage only after an app or pipeline has already been used as the entry point.

How It Works in Practice

The right handling pattern starts with removing the secret from every place that expands its blast radius. Put it in a managed secrets system, load it at runtime, and restrict retrieval to the workload identity that truly needs it. For server-side applications, a client secret may still be acceptable if the app can protect it in a backend boundary, but it should never be embedded in browser code, mobile binaries, public repos, or long-lived configuration files.

For native apps and SPAs, current guidance is straightforward: do not use a static client secret. Use PKCE, because the client cannot reliably protect a shared secret in hostile client environments. For service-to-service flows, pair short-lived credentials with workload identity so the application proves what it is before it is allowed to authenticate. That is consistent with the OWASP Non-Human Identity Top 10, which treats lifecycle discipline and secret exposure as first-class risks.

Operationally, a strong pattern looks like this:

• Store the OIDC client_secret in a secrets manager or vault, not in code or environment files checked into source control.
• Restrict retrieval to the production workload identity and deny human reuse.
• Rotate secrets on a defined schedule and immediately after any suspected exposure.
• Log access to the secret itself, but never log the secret value.
• Use PKCE for public clients and keep auth flows free of embedded secrets.

Entro Security found that 44% of NHI tokens are exposed in the wild, often in Teams, Jira, Confluence, and commits, which underscores why “hidden in config” is not a control. The same pattern is visible in NHIMG’s Shai Hulud npm malware campaign coverage and the CI/CD pipeline exploitation case study, where pipeline trust becomes credential exposure. These controls tend to break down in legacy monoliths that cannot separate runtime secret loading from build-time packaging because the secret is baked into the artifact before deployment.

Common Variations and Edge Cases

Tighter secret handling often increases deployment complexity, so teams have to balance operational speed against exposure reduction. That tradeoff is real in multi-tenant platforms, hybrid estates, and older apps that expect a static configuration file.

There is no universal standard for every edge case, but current guidance suggests these boundaries:

• Confidential server-side apps can use OIDC client secrets if the secret is protected by strong runtime controls and rotated aggressively.
• Public clients, mobile apps, and SPAs should use PKCE and avoid static secrets altogether.
• Ephemeral secrets are preferable where the platform supports JIT issuance, especially for automated service accounts.
• Secrets shared across multiple apps should be retired; duplicated secrets expand the blast radius and complicate revocation.

Two common failure modes deserve special attention. First, teams assume a private repository is safe, but NHIMG research consistently shows that secrets surface in tickets, wikis, logs, and build systems as often as they do in source. Second, teams rotate the secret but leave the old one active, which means detection happens without real containment. The Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because it frames why short-lived credentials reduce exposure when applications can support them. For governance baselines, OWASP Non-Human Identity Top 10 and 52 NHI Breaches Analysis both reinforce that lifecycle failure, not just theft, is the real risk. Many environments fail here because the application architecture was never designed to prove workload identity separately from secret possession.

Related resources from NHI Mgmt Group

• How should security teams handle secrets in AI-generated code?
• How should security teams protect HMAC secrets in production systems?
• How should security teams handle secrets in frontend applications?
• How should security teams migrate workloads away from long-lived secrets?