An AI agent running in GitHub Actions needs to push artifacts to an AWS S3 bucket. A developer proposes storing AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as GitHub Actions secrets. A security architect recommends using GitHub Actions OIDC instead. What is the primary security advantage of the OIDC approach over stored AWS credentials?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Static AWS credentials are like a permanent key to your house: if someone copies it, they have indefinite access until you change the locks. OIDC credentials are like a one-time door code: they're issued fresh for each visit, expire automatically, and cannot be reused from anywhere else. The correct answer is B.
Full explanation below image
Full Explanation
GitHub Actions OIDC integration with AWS works by configuring AWS IAM to trust GitHub's OIDC provider. When the workflow runs, it obtains a signed OIDC token from GitHub (identifying the specific repo, branch, and workflow) and presents it to AWS STS's AssumeRoleWithWebIdentity endpoint. AWS verifies the token's signature against GitHub's public key and issues temporary credentials (access key, secret key, session token) that expire after a short duration (typically 1 hour).
The primary security advantage is the elimination of long-lived credentials: there are no AWS access keys stored anywhere — not in GitHub Secrets, not in configuration files, not anywhere. The OIDC token itself is short-lived and tied to the specific workflow run via the run_id claim, making it valid only within that execution context.
If an AWS access key stored in GitHub Secrets is leaked (through a log, a compromised runner, or a misconfigured workflow), the leaked key provides indefinite AWS access until manually rotated. Rotation requires detecting the leak, generating new keys, updating the secret, and revoking the old key — all manual steps.
With OIDC, a leaked OIDC token is only valid for the current workflow run (typically minutes) and the resulting AWS temporary credentials expire automatically within the configured session duration.
Option A is incorrect because GitHub Secrets encrypts secrets at rest using strong encryption. The comparison is not about encryption at rest — it is about the duration and revocability of the credentials.
Option C is incorrect because OIDC adds an additional token exchange step (obtaining the OIDC token and calling STS) and is slightly slower than direct IAM authentication. The advantage is security, not performance.
Option D is incorrect because AWS access keys can be used in GitHub Actions via environment variables — many workflows use this approach. The recommended approach is OIDC, not because keys cannot be used, but because OIDC is more secure.