OIDC

Overview

Nullify's OIDC connectors establish keyless trust between Nullify and your identity, version-control, and cloud providers. Instead of storing long-lived credentials, Nullify runs OpenID Connect (OIDC) issuers that mint or publish short-lived, signed tokens. The relying party (AWS Cognito for sign-in, or a cloud provider's federation service for infrastructure access) verifies those tokens against a public key, so no static secret is ever shared.

Each connector is a small OpenID Connect provider. Some bridge a provider's OAuth2 endpoints into a standard OIDC flow used for single sign-on; one publishes only the public signing key used for cloud workload-identity federation.

How OIDC trust works

There are two patterns across the connectors:

• OAuth-to-OIDC sign-in bridges (GitHub, Azure, Bitbucket, GitLab) — These providers expose OAuth2 but not native OpenID Connect. The bridge wraps their OAuth2 flow, signing a standard ID token (RS256) so that AWS Cognito and similar relying parties can authenticate users and capture provider context (installations, workspaces, organizations, groups) during sign-in. Each exposes the standard endpoints /.well-known/openid-configuration, /authorize, /token, /userinfo, and /jwks.json.

• Cloud workload-identity federation (GCP) — Nullify publishes only a discovery document and a JWKS endpoint. Your cloud project trusts the Nullify issuer, and a federation service exchanges a Nullify-signed token for a short-lived cloud credential scoped to your tenant — no service-account key is ever exported.

In both patterns, JWT signing uses an RSA key pair whose private key stays in Nullify's AWS SSM Parameter Store and whose public key is served from the issuer's /jwks.json (or /.well-known/openid-configuration).

Supported providers

Provider	Issuer URL	Purpose
GitHub	https://github.nullify.ai	OAuth-to-OIDC bridge for sign-in; enriches claims with GitHub App installation and owner data.
Azure	https://azure.nullify.ai	OAuth-to-OIDC bridge for sign-in; captures Azure DevOps organizations and projects via Microsoft Graph + Azure DevOps.
GCP	https://gcp.nullify.ai	Workload Identity Federation issuer; publishes the public key Google STS uses to verify Nullify-signed subject tokens.
GitLab	https://gitlab.nullify.ai	OAuth-to-OIDC bridge for sign-in; enriches claims with GitLab group membership.
Bitbucket	https://bitbucket.nullify.ai	OAuth-to-OIDC bridge for sign-in; enriches claims with Bitbucket workspace and repository data.

Issuer URLs above are the production hosts. Development environments use the equivalent *.dev.nullify.ai subdomain (for example, https://gcp.dev.nullify.ai).

Provider notes

GitHub

GitHub exposes OAuth2 endpoints but has no native OpenID Connect support. The GitHub connector wraps GitHub OAuth2 as an OIDC provider for use with AWS Cognito. During sign-in, /userinfo fetches the user and their GitHub App installations concurrently and adds github_install_ids, github_owner_ids, and github_owner_types claims so Nullify knows which installations a user can access. GitHub Enterprise is supported by pointing the connector at a custom GitHub base URL.

Azure

The Azure connector bridges Azure AD OAuth2, Microsoft Graph, and Azure DevOps into a single OIDC flow, primarily to capture the Azure DevOps organizations and projects a user can access at sign-in. It runs a multi-step on-behalf-of (OBO) token flow: it exchanges the auth code, then requests OBO grants for Azure DevOps and Microsoft Graph, and bundles the resulting tokens so /userinfo can enumerate the user's organizations.

GCP

Unlike the OAuth bridges, the GCP issuer performs no OAuth flows (no /authorize, /token, or /userinfo) and signs no tokens itself. It is deployed once per environment as a shared multi-tenant platform service and publishes only the discovery document and the RSA public key. Your project creates a Workload Identity Pool that trusts https://gcp.nullify.ai, with an attribute_condition that pins access to your Nullify tenant id (assertion.tenant_id == "<your tenant id>"). A Nullify tenant lambda signs an OIDC token and passes it to Google STS, which fetches https://gcp.nullify.ai/jwks.json to verify the signature before returning a federated, tenant-scoped credential.

GitLab

The GitLab connector wraps GitLab OAuth2 as an OIDC provider, enriching the signed claims with the user's GitLab group membership so Nullify can map the user to the right repositories during sign-in.

Bitbucket

The Bitbucket connector wraps Bitbucket OAuth2 as an OIDC provider for use with AWS Cognito, enriching claims with the user's workspace IDs, names, and slugs, plus repository full names. Repository and workspace lookups are best-effort: failures are logged but do not block sign-in.

Setup

OIDC trust is provisioned by Nullify as part of onboarding your tenant. For cloud federation (GCP), you will create a Workload Identity Pool that trusts the Nullify issuer; your Nullify representative provides the exact pool and attribute-condition configuration for your tenant. For sign-in bridges, no customer-side OIDC configuration is required — the connectors are wired into the Nullify authentication flow automatically.

For related cloud-context setup, see the AWS, GCP, and version-control connector guides.