OIDC misconfigurations are becoming a primary NHI attack vector

At a glance

What this is: This article argues that OIDC replaces password handling with a new set of identity controls, where client secrets, JWT validation, and cloud trust policies become the real security boundary.

Why it matters: It matters because IAM, NHI, and CI/CD teams now have to govern token-based trust with the same discipline once reserved for passwords and keys.

👉 Read GitGuardian's analysis of OIDC misconfigurations and NHI attack paths

Context

OpenID Connect is an authentication layer built on OAuth 2.0, but in practice it shifts the security burden from passwords to secrets management, token validation, and trust policy design. In CI/CD and workload identity patterns, the primary governance question is no longer whether authentication works, but whether integration logic and token boundaries are tightly controlled.

For non-human identities, the risk is not the protocol itself but the way developers implement it. Client secrets are treated as configuration, JWT claims are partially checked, and cloud trust policies are widened beyond the intended subject or branch scope. That combination creates a governance gap that identity programmes often miss until credentials are already in use.

Key questions

Q: What breaks when OIDC client secrets are treated as configuration?

A: The application turns a credential into an exposure-prone setting, which means source code, container files, logs, and frontend bundles can all become paths to impersonation. In practice, that removes the boundary between development convenience and access control, and attackers only need one leaked secret to act as the application.

Q: Why do weak OIDC claim checks create impersonation risk?

A: Because a valid signature only proves that the token was issued by a trusted key, not that it was issued for the right application. If the audience and issuer are not checked, a token minted for one service can be replayed against another, which is the confused deputy failure pattern.

Q: What are the signs that an OIDC trust policy is too broad?

A: Look for wildcarded subject rules, branch-agnostic allowlists, and trust conditions that accept whole repositories or entire organisations instead of one deployment path. Those patterns indicate that temporary federation is being used as if it were unrestricted standing access, which expands blast radius across workflows.

Q: How should security teams govern OIDC and workload tokens in release pipelines?

A: Treat OIDC and other workload tokens as privileged identities with explicit audience, repository, and job restrictions. Do not grant broad federation by default. Pair token scoping with workload segregation, so a compromised job cannot reuse its identity to publish code, access cloud services, or move into adjacent pipelines.

Technical breakdown

Client secrets in OIDC are credentials, not configuration

In the authorization code flow, the application must prove itself to the identity provider with a client_secret. That secret is equivalent to a password for the application, so storing it in source code, container files, logs, or frontend bundles turns identity trust into a leakage problem. PKCE removes the need for static secrets in public clients, but server-side applications still need protected storage and rotation. The real architectural mistake is assuming that because the IdP handles authentication, the integration layer no longer contains sensitive material.

Practical implication: Treat every client_secret as a high-value credential and remove static secrets from environments that cannot protect them.

JWT validation is more than signature verification

A signed JWT can still be unsafe if the application does not validate the issuer, audience, and expiration claims. Signature verification only proves the token was issued by some trusted key, not that it was issued for this application. The audience claim binds the token to a specific client_id, which is what prevents a token minted for one app from being replayed against another. This is the core confused deputy failure: the application accepts a valid token that was never meant for it.

Practical implication: Validate iss, aud, exp, and allowed algorithms on every token before the application trusts any claim.

OIDC trust policies become the control plane for non-human identity

Workload identity federation replaces long-lived cloud keys with short-lived tokens, but the trust policy becomes the logic secret that decides which workload is allowed to exchange a token for cloud credentials. If the subject claim is wildcarded too broadly, any branch, fork, or workflow within the allowed namespace can inherit access that was meant for one deployment path only. That makes trust policy scope a privileged control, not a convenience setting. The same identity primitive that reduces key sprawl can also widen blast radius when policy logic is loose.

Practical implication: Scope federated trust policies to the exact repository, branch, and environment claims that should be allowed.

Threat narrative

Attacker objective: Obtain trusted access through OIDC misconfiguration and use it to impersonate workloads or reach cloud and backend resources with elevated privileges.

1. Entry begins when an attacker finds a leaked client_secret in source control, logs, or a build artifact, or when they abuse a weakly scoped OIDC integration that already trusts too much. Credential access is often the first foothold because the secret or token boundary is exposed inside the development workflow rather than at the IdP.
2. Escalation occurs when token validation is incomplete or a cloud trust policy accepts broad subject patterns, allowing a token issued for one workflow to be accepted by another. The attacker does not need to break cryptography; they only need the application to trust the wrong token or the cloud role to trust the wrong subject.
3. Impact follows when the attacker exchanges the valid token for cloud credentials or application access and uses that foothold to reach production systems, trigger downstream actions, or gain administrative privileges in backend resources.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OIDC does not remove identity risk, it relocates it into integration logic. The protocol reduces password handling, but the burden shifts to how secrets, claims, and trust policies are implemented. That relocation is exactly where NHI governance has to focus, because the failure is no longer user authentication but token-bound access control across CI/CD and cloud workloads. Practitioners should treat OIDC as a lifecycle and policy problem, not a login problem.

Client secret leakage is an NHI governance failure, not a developer convenience issue. The article shows that a client_secret functions like a password for the application, which means it belongs under the same control discipline as any other credential. Treating it as config creates an exposure window that is easy to overlook in pipelines, containers, and source control. The implication is that NHI programmes must classify OIDC application secrets as governed identities in their own right.

The OIDC trust policy is the new standing privilege boundary. In workload identity federation, the policy decides which workload can exchange a token for cloud access, so broad subject matching behaves like overprivileged access. This is where identity blast radius is created: the access is temporary, but the trust rule can still be too broad. Practitioners should evaluate policy scope with the same rigor they apply to privileged role design.

Token validation gaps expose a confused deputy pattern that traditional IAM reviews often miss. A valid JWT is not enough if aud and iss are not checked, because the application may accept a token issued for a different audience. This is a governance assumption failure, not a cryptographic failure: teams assume the IdP-issued token is automatically fit for the target service. The implication is that identity assurance now depends on application-level claim binding, not just federation presence.

OIDC has become a primary attack vector because it sits at the intersection of human IAM, NHI, and delivery pipelines. The same control failure can start as a developer secret leak, continue as a misvalidated JWT, and end as cloud privilege abuse. That cross-domain path is why identity teams need shared ownership across app teams, platform teams, and IAM governance. The discipline is no longer siloed by user versus workload identity.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to the State of Secrets in AppSec.
• Read next: Guide to NHI Rotation Challenges

What this signals

Client secret discipline has become an identity control, not a developer preference. OIDC only reduces risk when the integration layer stops treating secrets as configuration and starts treating them as governed credentials. The operational question for teams is whether their build and deployment paths can expose a client_secret without triggering the same response they would use for a password leak.

OIDC trust policy drift is a form of privilege creep. As workload identity federation expands, subject matching rules often widen to accommodate convenience, forks, or pipeline reuse. That drift silently increases the number of workflows that can exchange a token for cloud access, so teams need to review the policy logic with the same rigor they apply to privileged role assignments.

Token validation must move from library assumption to explicit control. Many implementations rely on signed tokens and default settings, but the security boundary depends on audience and issuer binding. When those checks are omitted, the application accepts an identity assertion that was never intended for it, which is why OIDC misconfiguration belongs in the same governance conversation as secrets management.

For practitioners

• Classify OIDC client secrets as governed credentials Move client_secret values into a dedicated secrets manager, prohibit hardcoding in repositories or container definitions, and treat any exposed secret as an immediate credential event.
• Enforce full token claim validation Require issuer, audience, expiration, and algorithm checks in every OIDC implementation, and block deployments that rely on decode-only logic or library defaults.
• Scope workload trust policies to exact subjects Restrict federated cloud trust to the precise repository, branch, environment, or workflow identity that should receive credentials, with no wildcard expansion.
• Review CI/CD paths as identity boundaries Audit pipelines, build logs, and deployment workflows for leaked OIDC artifacts, then map where token exchange can lead to production access.

Key takeaways

• OIDC changes the security problem rather than removing it, because client secrets, JWT validation, and trust policies become the actual control surface.
• The article links misconfiguration to real-world exposure through leaked secrets and overly broad workload trust, which is why CI/CD is now part of identity governance.
• The strongest preventive control is explicit claim validation plus narrowly scoped federation policy, because the protocol is only as safe as the integration rules around it.

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.
• Audience Claim: The audience claim is the value inside a token that identifies who or what should accept it. For non-human identity governance, it is the enforcement point that prevents a token issued for one resource from being accepted by another resource with a different trust boundary.
• Issuer Claim: The issuer claim identifies the trusted authority that created the token. It helps the receiving system decide whether the token came from a source it is prepared to trust. Validation against the issuer is a basic control for preventing tokens from unauthorized or unexpected identity providers.
• Workload Identity Federation: A mechanism allowing workloads in one environment to authenticate to another using short-lived tokens rather than stored credentials, based on mutual trust between identity providers.

What's in the full article

GitGuardian's full article covers the implementation detail this post intentionally leaves for the source:

• Step-by-step JWT validation logic for Authlib, including issuer, audience, expiration, and algorithm checks
• Examples of OIDC trust policy patterns for workload identity federation in GitHub Actions and cloud platforms
• Practical guidance on where to store client secrets and how to avoid hardcoding them in application and pipeline files
• Operational pitfalls in redirect URI handling, PKCE usage, and .well-known discovery endpoint management

👉 GitGuardian's full article covers JWT validation examples, trust policy pitfalls, and CI/CD secret handling details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.