When configuring OpenID Connect between GitHub Actions and a cloud provider, what is the role of the token audience (aud) claim?
Select an answer to reveal the explanation.
Short Explanation and Infographic
The aud claim says who the JWT is for—cloud STS validates it and rejects mismatches. It is not CODEOWNERS data, not a git push permission wand, and not a billing page label.
Full explanation below image
Full Explanation
GitHub’s OIDC provider issues short-lived JWTs that cloud platforms (AWS IAM, Azure federated credentials, GCP WIF, etc.) verify. The audience claim targets a specific relying party; misaligned aud causes token rejection. Workflows may customize audience where supported so tokens are only valid for your cloud federation configuration. sub and other claims further restrict which repo, environment, or ref may assume a role. OIDC does not embed CODEOWNERS, does not by itself grant git write beyond GITHUB_TOKEN permissions, and is not a billing display field. Best practice: prefer OIDC over long-lived cloud static keys stored as secrets, scope IAM roles tightly, and require environment protection for production cloud roles.