C1 (formerly ConductorOne)
B C1 Identity Platform (API + Baton connectors)
Service principals can swap an OIDC token from any issuer you register (or a SPIFFE JWT-SVID) for a 30-minute C1 token, with CEL conditions on the claims, so no C1 secret has to exist. Into your tenants it is keyless for AWS, Entra ID and Salesforce, but GCP, Google Workspace, Okta, GitHub, Slack and Azure RBAC still want a key or token you create and paste.
Docs: c1.ai · Checked 2026-10-13 · source YAML · dispute via PR
Inbound A
How a workload running anywhere authenticates to this product.
Workload federation on service principals: register any HTTPS OIDC issuer (presets for GitHub Actions, GitLab, HCP Terraform, AWS IAM outbound federation, SPIFFE, or Custom OIDC), bind it to a service principal with a CEL condition on the JWT claims, and exchange the JWT via RFC 8693 token exchange for a short-lived C1 access token.
- Issuers
- any
- c1.ai checked 2026-10-13
“Workload federation eliminates stored secrets entirely.”
- c1.ai checked 2026-10-13
“Built-in presets are available for GitHub Actions, GitLab CI/CD, HCP Terraform, AWS IAM, and SPIFFE. Use "Custom OIDC" for any other provider.”
- c1.ai checked 2026-10-13
“C1 validates the token: issuer, signature, audience, freshness, and your conditions”
- c1.ai checked 2026-10-13
“Any platform that issues OIDC tokens can be used with workload federation.”
- c1.ai checked 2026-10-13
“CreateProvider registers a new external OIDC issuer for the tenant.”
- c1.ai checked 2026-10-13
“Contact your C1 account team to enable the feature.”
- c1.ai checked 2026-10-13
“Your new API key is created and the client ID and client secret are shown.”
- c1.ai checked 2026-10-13
“Connectors authenticate using OAuth2 client credentials:”
Genuine bring-your-own-issuer: any issuer with OIDC discovery and a public JWKS can be registered (issuer URL immutable after creation), and each trust constrains by CEL over all claims (sub, repo, ref, etc.), optional IP allowlist and scoped roles. Audience is not free-form: the JWT's aud must contain the C1 tenant domain. Exchanged tokens are Bearer with expires_in 1800 in the documented example. Service principals (and so federation) must be enabled by the C1 account team and created by a Super Admin; no paid plan gate is documented, so tier_gated is left empty. The fallback paths are static: personal API keys (client ID + secret, optionally non-expiring) and service-principal client credentials (Ed25519 key, max 180 days, optional DPoP). Self-hosted Baton connectors authenticate back to C1 with a connector client ID and client secret (OAuth2 client credentials, minted with a "Rotate" button on the connector page); the docs do not show a federation option for them, so an on-prem connector still carries a static C1 secret.
Outbound B
How this product reaches into your cloud, repos, or other SaaS.
Cross-account IAM role with an External ID for AWS, plus C1-owned OAuth apps for Entra ID and Salesforce; GCP and Google Workspace want an uploaded service-account JSON key, Okta an API token or a customer-created OAuth app private key, GitHub a PAT or customer-created GitHub App private key, Slack a pasted OAuth token, and Azure RBAC a client secret.
- c1.ai checked 2026-10-13
“C1 uses an IAM Trust relationship between your AWS Account and C1's Service AWS Account.”
- c1.ai checked 2026-10-13
“AWS requires the use of External IDs when granting third-party access to your AWS account.”
- c1.ai checked 2026-10-13
“Follow these instructions to set up a built-in, no-code connector hosted by C1 using OAuth.”
- c1.ai checked 2026-10-13
“Log in and authorize C1 with your Salesforce instance.”
- c1.ai checked 2026-10-13
“The connector requires a JSON key, so confirm you can create one before you start.”
- c1.ai checked 2026-10-13
“Download the service account's JSON key”
- c1.ai checked 2026-10-13
“The OAuth 2.0 Private Key method is recommended for production environments because it provides scoped access with short-lived tokens rather than a long-lived API token.”
- c1.ai checked 2026-10-13
“To set up the GitHub connector, you can choose to create a personal access token (classic), a fine-grained access token, or a GitHub app.”
- c1.ai checked 2026-10-13
“Your user OAuth token is created. Copy and save the token value.”
- c1.ai checked 2026-10-13
“Next, we'll generate a client secret for this app. Click Certificates & secrets.”
Connectors checked: AWS, Entra ID, Azure, GCP, Google Workspace, Okta, GitHub, Salesforce, Slack. Keyless: AWS (cloud-hosted path assumes a role in your account trusted to arn:aws:iam::765656841499:role/ConductorOneService, with a C1-provided External ID; AWS China is self-hosted only and uses static access keys or IRSA), Entra ID (OAuth / admin-consent tab; client-secret and certificate tabs also exist), Salesforce (OAuth login to C1; JWT bearer, client-credentials and username/password paths also exist). Static: GCP and Google Workspace (service-account JSON key with domain-wide delegation; the docs warn new Google orgs block key creation by default), Okta (API token, or a customer-owned OIDC app's private key, which is C-shaped), GitHub (classic/fine-grained PAT or a GitHub App the customer creates and whose private key they hand over; no C1-owned GitHub App install), Slack (customer-created app token), Azure RBAC (app registration client secret). Least-privilege guidance is good throughout (custom read-only Okta role, scoped GitHub permissions), but not keyless. 400+ other connectors were not individually assessed.
Hygiene for any static credential the product still issues
| ✓ Expiry enforceable | Service-principal credentials have a hard 180-day ceiling (90 days is the recommended default) and Super Admins get digest alerts for credentials expiring within 30 days. Personal API keys, however, can be created without an expiry and no tenant policy forcing one is documented; this passes on the machine-principal credential, not the personal key. |
| ✓ Rotation via API | Personal API clients also have create/update/delete endpoints. |
| ✓ Scoped keys | Scoping is coarse (Full, Basic User, Read-Only Administrator, Read-Only to System Logs), but it is a purpose-built machine principal with its own role assignment, plus per-credential IP allowlists.
|
| ✓ Last-used visible | Both the service-principal credential and personal client schemas expose a read-only lastUsedAt timestamp. |
| ✗ Leak revocation | Neither C1 nor ConductorOne appears in GitHub's supported secret-scanning patterns, partner or otherwise, so a leaked client secret is not auto-revoked.
|
Notes
ConductorOne renamed itself C1 in April 2026; docs moved to c1.ai but tenant hostnames are still *.conductor.one (c1eu.ai for EU) and SDK env vars keep the CONDUCTORONE_ prefix. Workday announced its acquisition of C1 on 2026-10-12; the deal had not closed as of this check. Docs are public (including the OpenAPI-derived API reference), so nothing here relied on gated material. C1 also vends short-lived credentials outward for agents and MCP servers (Agent SSO, AWS AssumeRoleWithWebIdentity with a C1-issued OIDC token); that is a product feature, not how C1 itself reaches your tenants, and is not graded here. Outbound would rise to A if C1 offered GCP impersonation/WIF, a C1-owned GitHub App and Okta OIN service app, and a federated credential for Azure RBAC.
Badge
[](https://wif.tax/p/c1-identity-platform/)