Customizable audience claim in OIDC tokens
complete
Nathan Smith
A key security aspect of OIDC tokens is that an issuer provide them with audience fields specific to the third-party they will be used to autheniticate with.
For example: A token issued to authenticate to AWS should have an audience set to
sts.amazonaws.com
for example. This ensure that tokens issued to authenticate with one party and not abused to authenticate against a different one should the token be leaked accidentally.
It would be awesome if the OIDC tokens now injected into builds in the CIRCLE_OIDC_TOKEN environment variable could have specific audiences set instead of the current Org UUID which provide no additional meaningful information to create policy information against (indeed it is already encoded in the subject).
Oran Wilder
Enhancement announcement: Based on popular feedback, the aud claim for OIDC tokens can now be customized at the job level within config. Learn how: https://circleci.com/docs/oidc-tokens-with-custom-claims/
Oran Wilder
complete
OIDC audience claims can now be customized at the org and project level via the API. Learn how: https://circleci.com/docs/api/v2/index.html#tag/OIDC-Token-Management
Nathan Smith
Oran Wilder: Hey Oran! This is great to see and will functionally allow CircleCI to work with Sigstore and other projects to some degree. Unfortunately, this design still has the same security flaw as originally described in this issue -- namely that if you only allow appending more audiences to the _same_ token at a project or organization level there is risk of token replay between two audiences / clients.
As an example, imagine you want to authenticate to service A and service B from your build. In this case you'd set the audience to something like [ "service A", "service B"] on that project and each service should see that it is in the audience list and accept the token. The problem is that if service A gets compromised or is acting maliciously, it can take the token it received from your build and use it to authenticate to service B.
This is why it is critical to be able to get tokens with strictly an audience of "service A" and use them with service A and _different_ tokens with "service B" and use them with service B.
Nathan Smith
Oran Wilder: Does the final pipeline OIDC Token take the union of org level claims and project level claims or does project level override org level? I wasn't able to tell from the API docs
Oran Wilder
Nathan Smith: It sounds like some continuing work on tokens will resolve this. Job-level custom claims are next on our list.
Oran Wilder
Nathan Smith: Good callout for improving our docs. The project level claims will override the org level claims.
Oran Wilder
in progress
F
Francois Proulx
Any updates ?
William Woodruff
Hi there! Has there been any progress on this functionality? We'd love to support CircleCI's ambient credentials in
sigstore-python
, and a customizable claim is our primary requirement :-)William Woodruff
For context, we're tracking it on our end here: https://github.com/sigstore/sigstore-python/pull/72
Nathan Fish
planned
Nathan Smith
If this audience claim was customizable, it would allow the CircleCI OIDC tokens to be used with https://sigstore.dev. Sigstore is makes it easy to sign containers and other artifacts without having to worry about key management. Folks are currently signing over 8000 artifacts a day in Github Actions from ~500 different repositories using this method