Introduction

The use of static credentials in CI/CD pipelines introduces several operational and security challenges. Access keys require regular rotation, and if rotations are missed or delayed, pipelines can fail unexpectedly during deployments. On my current project, credential rotation used to depend on another internal team, creating an external dependency for deployment reliability. This created the additional risk of sudden pipeline failures during production deployments, often requiring another team to urgently intervene before releases could proceed.

Background of OpenID Connect (OIDC)

OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 protocol, designed to enable applications and services to securely authenticate users and workloads without directly handling long-lived credentials.

Traditionally, applications and platforms authenticate to external systems using static credentials generated by the target service provider and stored within the calling platform itself. For example, in the Azure DevOps and AWS integration model, AWS generated long-lived access keys which were then stored inside Azure DevOps service connections and sent during deployment operations to authenticate pipeline requests.

With OIDC, applications and platforms no longer store or send static credentials during authentication operations. Instead, a trusted identity provider authenticates the requesting entity and issues a short-lived signed token to the requesting entity containing identity claims, the requesting entity then sends to the short-lived token to the target service provider which validates the token with the identity provider before temporarily granting access.

A useful real-world example is how temporary passes work when you visit an office building.

Imagine you’re visiting an office building. When you arrive, reception first verifies who you are using a trusted form of identification. Once verified, they issue you a temporary visitor pass. You then use that pass to access secure areas of the building. The lifts and the doors systems trust the visitor pass because it was issued by a trusted reception desk, not because they know you personally. When your visit is over, the pass expires and can no longer be used.

OIDC works in a very similar way. Instead of a person, an application or pipeline proves its identity to a trusted Identity Provider. The Identity Provider issues a temporary token, which is then presented to another service. That service trusts the token because it was issued by a trusted provider and grants temporary access based on that trust.

In traditional web applications, this process is commonly seen when users sign into applications using providers such as Google, Microsoft, or GitHub.

The same concept applies to CI/CD systems, except the requesting entity becomes the deployment platform rather than a human user. In this model, Azure DevOps never stores permanent AWS access keys. Instead, AWS temporarily grants access only after validating the signed identity token issued during pipeline execution.

While this section focused on the foundational concepts behind OIDC and the limitations of static credentials, the next part of this article explores how we implemented OIDC federation between Azure DevOps and AWS within a real enterprise deployment platform, including the migration strategy, trust relationships, cross-account access design, and operational challenges encountered during rollout.