Choose OIDC whenever the target service supports federation, because it replaces standing credentials with a short-lived token per step. Keep stored secrets only where the downstream service cannot accept federated identity, and then confine them to the narrowest deployment scope possible.
Why OIDC is usually the better default in Bitbucket pipelines
OIDC is the cleaner choice when the downstream platform can trust federated identity. It turns pipeline authentication into a short-lived, step-bound exchange instead of a reusable credential that must be stored, rotated, and protected. That reduces standing access, shrinks blast radius, and aligns better with modern secrets-minimisation and federation patterns.
For teams trying to compare options, the practical test is simple: if the target service can validate a federated token and issue access on that basis, OIDC usually offers less residual risk than a stored secret. The more often a pipeline runs, the more that difference matters, because repeat usage magnifies the operational burden and the exposure of long-lived credentials.
When the target only understands static credentials, stored secrets remain a compatibility fallback, but they should be treated as exception handling, not the preferred model. That means scoping them as narrowly as the service allows, keeping them out of broad shared contexts, and avoiding any design that turns a single secret into a cross-environment privilege path.
What changes operationally when you move from stored secrets to federation
The biggest change is not just token format, it is control model. A stored secret is something the pipeline can reuse until someone rotates it. An OIDC flow is something the pipeline obtains for a specific run or step, so access is tied to execution context rather than to an enduring secret value.
That difference affects how teams design deploy jobs, cloud access, and release automation. With OIDC, the trust decision moves to the identity provider, the token issuer, and the target service’s federation configuration. With stored secrets, the burden shifts to secret storage, distribution, rotation, leak detection, and manual recovery when the credential is suspected to be exposed.
Teams should also recognise that OIDC is not magically secure by default. It still depends on correct audience checks, issuer trust, token lifetime limits, and step isolation. If those controls are loose, federation can still be misused, just with a different failure mode than a leaked password or API key.
For background on the underlying model, OpenID Connect Core 1.0 defines the identity layer that makes federation possible, while RFC 6749: The OAuth 2.0 Authorization Framework explains the token-driven authorization model it builds on.
When stored secrets are still justified, and how to keep them contained
Stored secrets are justified when the consuming system cannot participate in federation, when the integration is legacy, or when a third-party service only accepts a static API key or client secret. In those cases, the decision is really about limiting exposure rather than pretending the control is equivalent to OIDC.
The containment rule is to scope the secret to the narrowest deployment path possible. Give it only the permissions needed for that one destination, avoid reuse across environments, and separate dev, test, and production credentials so a leak in one lane does not become a platform-wide incident.
Secrets also need a lifecycle. If you choose a stored credential, you inherit ownership of rotation, revocation, and leak response. That is why secret sprawl becomes the hidden cost of convenience, especially in CI/CD systems where credentials can be copied into logs, environment variables, build metadata, or multiple pipeline definitions.
The Secret Sprawl Challenge is a useful reminder that the real failure is often not the initial secret, but the way it gets replicated and left behind. For teams that need practical handling guidance, Secrets Management Guide covers the controls that matter once you are forced to keep static credentials.
Risk and Threat Considerations
Stored secrets create durable exposure: if one is copied, logged, or exfiltrated, an attacker can replay it until it is revoked or rotated. In CI/CD systems, that can turn a single pipeline credential into access to source, build, deployment, or cloud resources well beyond the job that used it.
Failure mechanism: A long-lived secret can be harvested from pipeline configuration, build output, environment variables, or a downstream service, then reused outside the original execution context because the service cannot distinguish legitimate pipeline use from abuse.
Impact: The compromise can persist across runs, environments, and sometimes repositories, which increases blast radius and makes incident response depend on rotation speed rather than on prevention alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Bitbucket stored secrets create durable credential exposure and rotation burden. |
| NHI-02 — Secret Leakage | Pipeline secrets can leak through logs, config, or build context. | |
| NHI-05 — Overprivileged NHI | Stored pipeline credentials often carry broader access than the job needs. | |
| Recommendation — Prefer short-lived federation and rotate any static secret on a strict TTL. Scan pipeline paths for secret leakage and remove exposed credentials immediately. Scope each credential to the minimum target, action, and environment. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | OIDC and static secrets both hinge on correct authentication to downstream services. |
| Recommendation — Validate issuer, audience, and token validation on every federated integration. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Pipelines and target services are nonhuman systems authenticating to each other. |
| IA-5 — Authenticator Management | Static pipeline secrets require lifecycle control, rotation, and revocation. | |
| AC-6 — Least Privilege | The choice between OIDC and secrets changes the blast radius of pipeline access. | |
| Recommendation — Use federated, service-to-service authentication instead of reusable shared secrets. Enforce rotation, revocation, and storage controls for any remaining secret. Limit each pipeline credential to the narrowest actions and resources possible. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | Stored pipeline credentials are authentication information that needs controlled handling. |
| A.5.15 — Access control | The question is about controlling which pipeline can access which service. | |
| Recommendation — Protect, rotate, and restrict access to every pipeline credential. Apply access control so each pipeline only reaches the intended service and scope. | ||
Practitioner Guidance
What to verify: Confirm that the target service validates issuer, audience, and token lifetime before you treat OIDC as the safe default. If any of those checks are weak, federation may still create broad or replayable access.
Decision rule: Use OIDC when the service supports it cleanly; use a stored secret only when federation is unavailable or operationally unreliable, and then bind it to a single purpose, environment, and deployment path.
Common mistake: Treating a stored secret as a generic pipeline credential. That usually produces credential reuse, wider blast radius, and harder incident recovery than teams expect.
Practitioner takeaway: Choose the mechanism that minimizes standing authority first, then constrain the exception. In Bitbucket pipelines, OIDC should be the default unless a real compatibility gap forces you back to static secrets.