Complete Guide to Setting Up OIDC Integration in GitHub

Read full article here: https://www.britive.com/resource/blog/getting-started-guide-britive-oidc-integration/?utm_source=nhimg

Why Non-Human Identity Security Matters

Modern enterprises are no longer run by humans alone. Non-Human Identities (NHIs), from service accounts and GitHub Actions workflows to IoT devices and Agentic AI agents, now outnumber human users across most environments.

But here’s the problem: many of these identities still rely on static credentials and long-lived tokens. These permanent secrets act like digital master keys, creating a wide-open attack surface. Real-world incidents, like the Internet Archive breach in October 2024, show the devastating impact of leaving static tokens unrotated and unmanaged.

To move beyond these risks, organizations must adopt dynamic, just-in-time (JIT) access and Zero Standing Privileges (ZSP). That’s where Britive’s GitHub OIDC integration comes in.

How Britive Secures GitHub Actions with OIDC

In this guide, we showcase a real-world implementation of securing GitHub Actions, a common NHI, by integrating GitHub with Britive using OpenID Connect (OIDC).

By replacing static credentials with short-lived, identity-bound tokens, Britive ensures every GitHub Action is tied to a business context, fully auditable, and granted access only when required.

Key Steps in the Integration:

1. Configure GitHub as an Identity Provider (IdP) in Britive
   • Set Issuer URL to GitHub’s OIDC issuer: https://token.actions.githubusercontent.com.
   • Map GitHub’s sub claim to a Britive attribute for identity tracking.
   • Restrict tokens to an Allowed Audience (e.g., britive) for stronger validation.

2. Define GitHub as a Service Identity in Britive
   • Assign federated attributes like:
   • repo:netJoints/britive-github-nhi:ref:refs/heads/main
   • This ensures only trusted workflows from the specified repo and branch can request tokens.

3. Attach the Service Identity to a Britive Profile Policy
   • Profiles grant temporary privileges to specific AWS, SaaS, or on-prem resources.

4. Configure GitHub Actions Workflows
   • Use OIDC tokens to dynamically request Britive credentials.
   • Example: A workflow that lists S3 buckets through Britive, with credentials injected just-in-time.

Real-World Outcome

With this setup, GitHub Actions workflows gain secure, ephemeral access to AWS S3. The workflow:

• Fetches a JIT credential from Britive.
• Lists S3 buckets securely.
• Checks the profile back in, ensuring no standing privileges remain.

Every action is logged in Britive’s audit trail, capturing:

• Which GitHub workflow triggered access.
• What resources were accessed.
• Whether access was human-initiated or automated.

This delivers full traceability for compliance and forensic investigations.

Why This Matters for Enterprises

Enterprises today face a reality where NHIs and AI agents vastly outnumber human users. Without proper governance, static secrets for these identities create one of the largest hidden attack surfaces in cloud and SaaS ecosystems.

Britive addresses this by:

• Eliminating static credentials.
• Enforcing JIT and ZSP for all NHIs.
• Providing complete auditability for compliance frameworks like SOC 2, PCI DSS 4.0, and ISO 27001.

Final Thoughts

The era of permanent keys and tokens is over. As the GitHub OIDC integration demonstrates, Britive empowers enterprises to secure NHIs and Agentic AI identities with the same rigor as human identities, without slowing down development.

By embedding security into automation pipelines, enterprises can embrace agility without compromising trust.