Custom OIDC Workflow

Expanded Definition

Custom OIDC Workflow describes an identity pattern where a platform, workload, or agent issues its own OpenID Connect token and uses explicit trust rules to exchange that token for downstream access. It is broader than a single CI/CD integration because the issuer, claims, audience, and validation logic are designed around the workload itself, not around a vendor default.

In Non-Human Identity operations, this pattern is used to replace long-lived secrets with short-lived, attestable credentials for services, Kubernetes service accounts, cloud workloads, and AI agents. The trust model must be defined with the same discipline expected in NIST Cybersecurity Framework 2.0: identity, authentication, authorization, and monitoring all need clear ownership. Industry usage is still evolving, so “custom” usually means the organisation controls the issuer or token exchange path rather than relying only on a hosted provider template.

The most common misapplication is treating any JWT-based workflow as OIDC, which occurs when teams skip issuer validation, audience restrictions, or token lifetime controls.

Examples and Use Cases

Implementing custom OIDC rigorously often introduces more policy design and validation overhead, requiring organisations to weigh secret elimination and portability against the cost of maintaining token trust boundaries.

• A Kubernetes workload uses a projected service account token to request cloud access, with claims mapped to a narrowly scoped role.
• An AI agent exchanges an internally issued OIDC token for a temporary API credential after passing policy checks on tool scope and environment.
• A platform team builds a federation layer for multiple services so each workload can authenticate without embedding static API keys in code or configuration.
• A CI pipeline mints a short-lived token tied to repository, branch, and runner identity, reducing exposure during build execution.

This pattern is often discussed alongside breach lessons such as the OneLogin API Key Vulnerability and the GitHub Action tj-actions Supply Chain Attack, where token handling and trust boundaries were central to exposure. For protocol semantics, OIDC specifications and federation guidance remain the baseline reference point, even when the implementation is custom.

Why It Matters in NHI Security

Custom OIDC Workflow matters because it is one of the cleanest ways to issue ephemeral, identity-bound access to non-human actors without relying on hardcoded secrets. When designed well, it supports least privilege, stronger rotation posture, and clearer revocation paths. When designed poorly, it creates a false sense of security because the token looks modern while the trust chain is still weak.

NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges. Those figures make custom OIDC especially important for governance, because the workflow can either reduce standing access or simply hide it behind a new issuer. The NIST Cybersecurity Framework 2.0 remains useful for mapping ownership, continuous monitoring, and response expectations around these workflows.

Organisations typically encounter token abuse, privilege escalation, or broken service-to-service access only after a secret leak, an expired claim, or an issuer compromise, at which point Custom OIDC Workflow becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How do custom OIDC attributes affect identity lifecycle control?
• What is OpenID Connect (OIDC) and how does it extend OAuth 2.0 for NHIs?
• Why can't OAuth 2.0 and OIDC alone fully solve NHI authentication challenges?
• How should organisations secure workflow platforms that handle both files and secrets?