No. OIDC replaces long lived cloud keys with short lived tokens, but it only works where the other side trusts your CI platform's tokens. Third party API keys, some package registry tokens, signing keys, and database passwords often remain. Use OIDC where supported, then manage the rest deliberately.
What OIDC does remove
GitHub states the benefit plainly: OIDC lets your workflows exchange short lived tokens directly with your cloud provider, so you stop storing long lived cloud secrets in GitHub. Each job receives a signed token. The cloud checks the token against your trust conditions and returns a short lived access token, valid only for a single job.
For the major clouds this removes the stored access key, which is usually the highest value secret in a pipeline.
What it leaves behind
OIDC needs a relying party that accepts the token. Anything that does not is still on a static credential. Typical leftovers:
| Leftover | Why OIDC does not cover it | Better option |
|---|---|---|
| Third party SaaS API keys | Service does not accept CI tokens | Store as an environment secret; scope it narrowly; rotate |
| Package registry publish tokens | Depends on the registry supporting trusted publishing | Use trusted publishing where offered; otherwise short lived scoped tokens |
| Code signing certificates | The key itself is the credential | Keep in a managed key service where possible; restrict to protected refs |
| Database passwords | Database may not accept OIDC | Fetch from a secrets manager with a job identity |
| Identifiers like client and tenant IDs | They are identifiers, not secrets | Fine to store as variables, though GitHub's Azure example keeps them as secrets |
The last row shows up in GitHub's Azure example, where the client ID, tenant ID, and subscription ID are read from secrets. These are identifiers. Whether you store them as secrets or variables is a style choice; the security comes from the federated credential on the Entra application.
The bridge pattern
For credentials that cannot go away, use OIDC as the key to a secrets manager. The job logs in with its token, the secrets manager releases a value after checking claims, and the value is short lived or at least not stored in CI. GitLab's Vault integration works this way: the job authenticates with an ID token and Vault returns the secret to the job.
OWASP's guidance supports this direction: credentials the pipeline uses to reach the secrets manager should be rotated frequently and expire after a job completes.
Steps to find what is left
- Run an inventory of repository, environment, organization, and Dependabot secrets.
- For each secret, name the service it unlocks.
- Check whether that service supports OIDC federation or trusted publishing. Check its own documentation; do not guess.
- Replace what you can, one service at a time, with a rollback plan.
- For the rest, move values into environments with branch rules and reviewers.
- Set rotation dates and owners.
- Re-check quarterly. Services add federation support over time.
The trust rule still matters
Moving to OIDC shifts the control from "protect the key" to "protect the trust rule". Write conditions on subject and audience, avoid wildcards, and give each role minimal permissions. A loose rule can be as dangerous as a leaked key, because anyone who satisfies it gets credentials.
Quick check
Is a pipeline with OIDC and no stored secrets fully safe?
No. Code running in a job can still request tokens and use whatever the role allows. Pin actions, review workflow changes, and keep roles narrow.
Are client and tenant IDs sensitive?
They are identifiers rather than credentials, but treat them as internal information and do not publish them needlessly.
Safeguard policies and gates can review pull requests that add credentials to workflows, and asset discovery helps find the pipelines in scope. A free scan is at gold.safeguard.sh/scan.
Sources
- GitHub Docs: About security hardening with OpenID Connect
- GitHub Docs: OpenID Connect in Microsoft Azure
- GitLab Docs: Use HashiCorp Vault secrets in GitLab CI/CD
- OWASP Secrets Management Cheat Sheet
Last reviewed: 19 October 2026.
