OIDC misconfigurations are becoming a primary NHI attack vector

At a glance

What this is: This guide explains how OIDC security fails when client secrets, JWT validation, and workload federation trust policies are treated as implementation details instead of governed credentials and access controls.

Why it matters: It matters to IAM and NHI practitioners because OIDC can replace static secrets only when identity boundaries, validation logic, and CI/CD trust conditions are explicitly controlled.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read GitGuardian's guide to OIDC security pitfalls, client secrets, and token validation

Context

OIDC is a federation pattern that removes passwords from the application, but it does not remove trust. The real governance gap appears in client secret handling, JWT claim validation, redirect controls, and workload identity federation policies that decide which identities can exchange tokens for access.

For IAM teams, the important shift is that authentication is no longer the end of the control plane. In CI/CD and agentic workflows, OIDC becomes an NHI governance problem because service identities, build runners, and automated deployments depend on token hygiene and policy precision. That is a typical failure mode in modern application stacks, not an edge case.

Key questions

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

A: Treat every OIDC client_secret as a privileged credential, not a configuration value. Store it in a managed secrets system, keep it out of source control and logs, and remove it from any browser-facing code. If the application is a native app or SPA, use PKCE instead of a static secret.

Q: Why do OIDC token validation failures create confused deputy risk?

A: Because a token can be real, signed, and still be wrong for your application. If the backend does not verify aud and iss, it may accept a token meant for another client and authorize the wrong requester. That turns the IdP into an unwitting deputy for an attacker.

Q: What is the difference between client secrets and workload trust policies in OIDC?

A: A client secret proves the application is allowed to exchange a code or token, while a trust policy decides whether a workload token may be exchanged for cloud access. The first is a secret credential, the second is access logic, but both must be tightly governed because both can be abused.

Q: Should organisations use OIDC for CI/CD and cloud workloads?

A: Yes, when the alternative is long-lived shared keys. OIDC reduces static credential exposure, but only if the trust policy is tightly scoped and the token validation is strict. If teams cannot control subject claims, audience checks, and revocation, OIDC can replace one risk with another.

Technical breakdown

Client secrets as high-value NHI credentials

In OIDC, the client_secret is the application’s proof of identity to the provider, so it behaves like a password for the workload. Server-side apps use it during the authorization code exchange, while native apps and SPAs should not store one at all. The common failure is treating it as configuration, which leads to hardcoding, log exposure, or accidental commits. Once exposed, the secret can be replayed to impersonate the application, especially when the app has broad downstream permissions. Practical implication: move client secrets into dedicated secrets management and remove static secrets from client-side code.

Practical implication: Store client secrets in a secrets manager and eliminate static secrets from any client-side or build artifact.

JWT validation and the confused deputy problem

A signed JWT is not automatically a valid JWT for your application. OIDC validation requires checking signature, issuer, audience, and expiry, because a token may be genuine but intended for a different client. The confused deputy problem appears when a backend accepts any token from the IdP instead of verifying that the aud claim matches its own client_id. Many libraries verify signatures by default, but skip critical claim checks unless configured. Practical implication: enforce explicit audience and issuer validation in every token-processing path, not just in one shared middleware layer.

Practical implication: Require explicit aud and iss checks wherever tokens are accepted, and fail closed if validation settings are incomplete.

Workload identity federation and trust policy scope

Workload identity federation replaces long-lived access keys with short-lived OIDC tokens issued by an external IdP, then exchanged for cloud credentials. The security boundary moves into trust policy logic, especially the subject claim and any environment or repository conditions. A precise policy binds access to a narrow workflow context, while a wildcard policy can let unrelated branches, forks, or test jobs inherit production access. This is where OIDC becomes an NHI issue: the trust policy acts like access control logic for non-human identities. Practical implication: review every subject condition as if it were a privileged access rule.

Practical implication: Treat trust policies as privileged access logic and remove wildcards from repository, branch, and environment conditions.

Threat narrative

Attacker objective: The attacker aims to exchange a compromised identity artifact for trusted access to cloud or application resources without needing a password.

1. Entry via leaked or hardcoded client_secret in source control, CI logs, or frontend bundles.
2. Escalation through token replay or a permissive trust policy that accepts tokens outside the intended application or workflow scope.
3. Impact through impersonation of the workload, unauthorized cloud access, or downstream administrative actions.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OIDC reduces password dependence, but it does not reduce identity governance complexity. The control surface simply shifts from human credentials to client secrets, token validation, and federated trust policy logic. That means IAM teams must treat every OIDC integration as a governed identity path, not a convenience feature. The practical conclusion is clear: authentication delegation without lifecycle control just moves the breach point.

Ephemeral authentication is not the same as ephemeral trust. Short-lived OIDC tokens can still authorize durable damage if the surrounding policy is too broad or the application skips claim validation. The security model therefore depends on the narrowest possible token audience, issuer checks, and subject conditions. Practitioners should assume that every unchecked claim becomes a policy exception in production.

Identity blast radius now depends on workflow context, not only credential lifetime. A stolen token or mis-scoped trust rule can reach far beyond the original application if the linked workload has privileged downstream access. That changes the governance conversation from secret rotation alone to access boundary design, approval, and continuous review. The practitioner priority is reducing the blast radius of every automated identity path.

Static secrets are only one half of the OIDC problem; logic secrets are the other half. Redirect URIs, audience checks, and trust policies behave like programmable controls that can fail just as badly as exposed credentials. This creates a governance gap that traditional secrets programs often miss because the risky artifact is configuration, not a string in a vault. The field needs to treat validation logic as part of NHI control inventory.

OIDC is now a workload identity standard with NHI consequences. As GitHub Actions, cloud providers, and CI/CD systems converge on token exchange, the weakest link becomes the policy that decides who the token belongs to and what it may do. That makes OIDC implementation quality a board-relevant issue for NHI governance. Practitioners should review federation flows with the same rigor used for privileged human access.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
• See Guide to the Secret Sprawl Challenge for the operational controls that close detection and revocation gaps.

What this signals

OIDC adoption is pushing identity governance into pipeline and platform operations. Teams that previously treated federation as a login concern now have to manage it as a workload control surface. The practical programme shift is to classify client secrets, token validation rules, and trust policies as NHI assets with owners, review cycles, and incident handling.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the broader pattern is clear: machine-to-machine trust breaks first where teams assume configuration files are harmless. That same assumption applies to OIDC trust policies and CI/CD automation, which is why secret inventory and policy review have to move together.

The next governance step is to connect OIDC implementation reviews to standards-based controls such as the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10. Doing so helps teams turn token handling, federation scope, and rotation discipline into auditable operational requirements.

For practitioners

• Inventory all OIDC client secrets Identify every application, pipeline, and service that uses an OIDC client_secret, then classify each one as a credential rather than configuration. Move secrets out of code, compose files, and build logs into a dedicated secrets manager, and remove them from any environment where developers can view source or pipeline output.
• Enforce closed-world token validation Require signature, issuer, audience, and expiration checks in every OIDC processing path. Reject any library configuration that skips aud validation, and standardize middleware so teams do not implement different validation rules across services.
• Narrow workload federation trust policies Bind cloud trust policies to exact repository, branch, and environment claims instead of wildcard patterns. Review any policy that allows repo-level or org-level matching, because broad subject conditions can turn any workflow into a credential broker.
• Rotate and revoke exposed OIDC credentials quickly Treat exposed client secrets and trust policy changes as incidents, not maintenance tasks. Pair detection with revocation runbooks so leaked artifacts stop being valid before they are reused in downstream token exchanges.

Key takeaways

• OIDC removes passwords from the user path, but it creates a governance burden around secrets, claims validation, and federation policy.
• The biggest operational failures are usually not cryptographic weaknesses. They are exposed client secrets, skipped audience checks, and overbroad trust rules.
• IAM and NHI teams should treat OIDC as a workload identity control plane, with inventory, validation, revocation, and review built in.

Key terms

• Client Secret: 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.
• Confused Deputy: A confused deputy occurs when a system with legitimate authority is tricked into acting on behalf of an attacker. In OIDC, this happens when a backend accepts a valid token without verifying that it was issued for that specific application, allowing token reuse across trust boundaries.
• Workload Identity Federation: Workload identity federation is a method for exchanging an external token for temporary cloud credentials without storing long-lived access keys. It reduces static secret exposure, but it only remains safe when trust policies tightly constrain subject, repository, and environment conditions.
• JWT Validation: JWT validation is the process of checking that a token is signed correctly and that its claims match what the application expects. For OIDC, that means verifying issuer, audience, and expiration, not just decoding the token and trusting its contents.

What's in the full article

GitGuardian's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step JWT validation examples for Authlib, including claims_options and algorithm restrictions.
• Concrete guidance on secure JWKS retrieval from the discovery endpoint and why hardcoding keys creates outage risk.
• Implementation pitfalls in GitHub Actions to AWS federation, including subject claim scoping and branch-level trust rules.
• Practical rotation guidance for client secrets and the limits of relying on detection alone.

👉 GitGuardian's full post covers JWT validation, workload federation risks, and secure implementation examples.

Deepen your knowledge

OIDC token validation and workload identity federation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for CI/CD, cloud workloads, or agentic systems, it is worth exploring.