> For the complete documentation index, see [llms.txt](https://docs.nullify.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nullify.ai/connectors/oidc.md). # 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 the relying party can verify their issuer and scope. Cloud workload federation avoids exporting a long-lived cloud key; sign-in bridges still require their provider-side OAuth application configuration. > 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 bridges adapt provider sign-in and enrich its context for Nullify. The bridge wraps the 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`. Azure is the exception: it captures only Entra sign-in identity here — Azure DevOps organization access is a separate, explicit consent (see [Azure](#azure) below). * **Cloud workload-identity federation** (GCP and Azure cloud) — 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. Nullify protects the private signing keys and publishes the public keys through each issuer's discovery document and JWKS endpoint. ## 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://entra.router.nullify.ai` | OAuth-to-OIDC bridge for Microsoft sign-in (Entra ID). Azure DevOps organization access is a separate consent, not captured here — see [Azure](#azure) below. | | **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. | ## 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 (Entra ID) OAuth2 into OIDC purely for **Microsoft sign-in**. It requests only OpenID Connect scopes (`openid profile email`) — never the Azure DevOps resource scope — so a customer who only wants Nullify as a Microsoft sign-in option never sees or grants Azure DevOps permissions. Connecting Azure DevOps organizations is a separate, explicit consent asked for by its own flow (**Connect Azure DevOps** in the dashboard), not by this sign-in bridge; see the [Azure DevOps connector](/connectors/azure.md) and its [install guide](/enterprise-tier/azure-install.md). The official production **Nullify** application (`37d9fe25-ca83-49ac-a099-054de06b1aad`) handles Microsoft sign-in and Azure DevOps connect independently. Customer consent creates the same enterprise application in their directory for either flow. SSO-only setup requests `openid profile email`. Azure DevOps setup requests those identity scopes plus delegated Azure DevOps `user_impersonation` access. The **Also enable Microsoft sign-in** option configures workspace sign-in after the ADO administrator's identity is verified; it does not change the ADO setup scopes or automatically grant workspace membership. {% hint style="info" %} **Security review notes.** Entra consent and Azure DevOps permissions are separate parts of the connection: * **Sign-in** — a tenant-wide delegated OIDC consent (`admin_consent=True`), which approves authentication scopes for the directory. A user still needs a linked or provisioned identity and an active role in Nullify. * **Azure DevOps setup** — delegated `user_impersonation` consent lets the signed-in administrator perform setup through Nullify. * **Ongoing Azure DevOps access** — the application's service principal needs organization membership, Basic access and scoped resource permissions in each connected organization. See the install guide's full permission table. The Nullify directory binding and each Azure DevOps organization connection are managed separately. Removing or disabling the shared enterprise application in Entra affects the application itself and can stop **both** flows: * To disconnect Nullify sign-in while retaining Azure DevOps, first disable Entra-only access with a verified Microsoft workspace administrator, then disconnect the directory in **Settings → Identity**. See [SSO setup and recovery](/configuration/account-and-teams/entra-sso-and-scim.md). Do not delete the shared enterprise application for an SSO-only disconnect. * To revoke Azure DevOps access for one organisation, go to that organisation's **Organization settings → Users** and remove Nullify's service principal (see [Removing Nullify's access](/enterprise-tier/azure-install.md#removing-nullifys-access)). For full offboarding, remove the Azure DevOps organization access and the enterprise application, and coordinate Nullify identity and credential removal. {% endhint %} ### 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 == ""`). 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 Nullify configures the sign-in bridge. Sign in at [app.nullify.ai](https://app.nullify.ai/). A new Azure DevOps workspace uses the [setup invitation](/enterprise-tier/azure-install.md#set-up-a-new-workspace). **Request workspace** does not claim a workspace Nullify has already prepared. For an existing workspace, directory consent, member linking, and Microsoft-only sign-in are [Entra SSO and SCIM setup](/configuration/account-and-teams/entra-sso-and-scim.md). You do not create a customer SSO app registration or supply Nullify an app secret. For GCP cloud federation, create a Workload Identity Pool that trusts the Nullify issuer using the tenant-specific attribute condition supplied by Nullify. For Azure cloud access, follow the separate [Azure cloud guide](/connectors/azure-cloud.md). For related cloud-context setup, see the [AWS](/connectors/aws.md), [GCP](/connectors/gcp.md), and version-control connector guides. ## Azure workload federation [Azure cloud](/connectors/azure-cloud.md) uses a federated credential on an Entra application, pinned to Nullify's issuer, audience, and tenant subject. It exchanges the signed workload assertion for Azure access without a stored client secret. This cloud-access flow is separate from Microsoft user sign-in and Azure DevOps consent. Use the issuer and tenant values displayed in your cloud settings; do not substitute a sign-in issuer merely because both use OIDC.