Originally published on kuryzhev.cloud
Every static AWS key sitting in your Jenkins credential store is a standing invitation. It works from anywhere, forever, until someone remembers to rotate it — which is rarely. Jenkins AWS OIDC authentication fixes this by making Jenkins prove who it is on every single run instead of handing it a permanent secret to carry around.
I've migrated three separate Jenkins fleets off static IAM users onto OIDC federation, and the pattern of mistakes is remarkably consistent across teams. This post covers what's actually happening under the hood, where people get it wrong, and the setup that holds up in production.
What this actually does
Jenkins, through an OIDC-capable plugin or a custom step, mints a signed JWT that describes the job: repo, branch, build ID, whatever claims you configure. AWS STS trusts that token — not because "Jenkins can access AWS," but because AWS has registered Jenkins' issuer URL as a trusted OIDC provider and will only accept tokens matching specific claim conditions. The exchange happens through AssumeRoleWithWebIdentity, which trades that signed token for temporary credentials.
