Custom Identity Providers on

Using Custom Identity Providers to Authenticate to Chainguard

Mon, 17 Apr 2023 08:48:45 +0000

The Chainguard platform supports Single Sign-on (SSO) authentication for users. By default, users can log in with GitHub, GitLab, and Google, but SSO support allows users to bring their own identity provider for authentication. This is helpful when your organization mandates using a corporate identity provider — like Okta or Azure Active Directory — to authenticate to SaaS products.

Usage

Once an administrator has configured an identity provider and set up their organization, users can authenticate at the command line and in the web console using the identity provider’s organization.

Grant Chainguard Roles from Identity Provider Groups

Wed, 01 Jul 2026 08:48:45 +0000

Chainguard can grant roles based on a user’s groups in your identity provider (IdP). You map an IdP group to a Chainguard role once, and from then on any user who logs in with that group in their token receives the role for that session. Access follows group membership, so you manage who gets what in your IdP instead of assigning roles to each user in Chainguard.

This guide covers Okta and Microsoft Entra ID. The Chainguard-side steps (2 through 4) are the same for both providers; only how you emit group membership in Step 1 differs.

Disabling Default Social Logins

Thu, 02 Jul 2026 08:48:45 +0000

By default, users can authenticate to the Chainguard platform with a built-in social login provider: GitHub, GitLab, or Google. After you configure a custom identity provider for single sign-on (SSO), you may want to require that everyone in your organization authenticate through that provider instead.

A common problem for SSO customers is that users click Login with Google (or another social provider) out of habit. Because a personal or non-federated Google account isn’t tied to your organization, this creates an account outside it that an owner then has to clean up and re-provision. Preventing social logins keeps account lifecycle, group membership, and security policies (such as multi-factor authentication) enforced centrally through your identity provider.

Enable PKCE for OAuth Token Exchange

Thu, 30 Jul 2026 08:48:45 +0000

You can add PKCE (Proof Key for Code Exchange, commonly referred to as “pixy”) to the OAuth token exchange between Chainguard and your custom identity provider (IdP). PKCE is a security extension to OAuth that adds an extra layer of protection against authorization code interception during login, and it is required by the OAuth 2.1 standard.

Chainguard supports two configurations, depending on your needs:

Client ID + client secret + PKCE — In this configuration, PKCE is layered on top of your existing confidential client setup. This is additive: you keep your client ID and client secret.
Client ID + PKCE only, no client secret — This is the newer “public client” model where PKCE replaces the client secret entirely, and is the approach OAuth 2.1 requires going forward.

Enabling PKCE is optional. If you leave PKCE disabled or optional on your IdP, your login behavior remains unchanged and you don’t need to take any action.

Identity Provider Examples

Thu, 16 Jan 2025 08:49:15 +0000