The aud claim names the service a token is intended for. A cloud provider should accept a CI token only if aud matches the value it expects. That check stops a token minted for one service from being replayed against another.
Definition
OIDC tokens are signed JSON web tokens. Besides who issued them (iss) and who they describe (sub), they carry an audience, aud, which is the recipient. Think of an envelope with an address on it. The signature proves the letter is real, and the address says who should read it.
What each platform says
GitLab's documentation is explicit. You set aud in the id_tokens configuration of a job, and if you do not set it, it defaults to the GitLab instance domain. Services can reject tokens whose audience does not match what they expect. Using a distinct audience per service limits how many services a stolen token can reach, and a missing or mismatched audience is a common cause of 401 unauthorized errors.
For AWS with GitHub Actions, the setup guide says to use sts.amazonaws.com as the audience when you use the official configure credentials action, and to validate the aud and sub claims in the trust policy condition.
For Microsoft Entra, a federated identity credential must list the audience that can appear in the incoming token. The recommended value is api://AzureADTokenExchange, and the docs say the field is required.
| Platform | Audience value in the docs |
|---|---|
| AWS with the official GitHub action | sts.amazonaws.com |
| Microsoft Entra federated credential | api://AzureADTokenExchange (recommended) |
| GitLab job token | Defaults to the instance domain unless you set it |
Why it matters
Imagine one job requests tokens for several services. If every token carried the same audience, a service that logged or mishandled its copy could leak a token that another service would still accept. With a distinct audience per service, the leaked token fails everywhere except where it was meant to work.
The audience check does not replace the subject check. Audience says "this token is for AWS". The subject says "and it came from this repository's deploy job". You need both conditions in the trust policy.
How to use it well
- Set an audience per destination, not one shared value.
- Write the audience as an exact match condition in the trust policy.
- Keep the audience out of places where tokens might be logged, and mask tokens in job output.
- When you add a second cloud, mint a second token with its own audience instead of reusing the first.
- When a login fails with unauthorized, compare the token's
audto the provider's expected value before anything else.
You can read a token's claims by decoding the middle section of the JWT in a throwaway job. Do this only for tokens in test pipelines, and never paste a production token into a website.
Quick check
What happens if aud is missing or wrong?
The provider should reject the token. GitLab's docs call a missing or mismatched audience a common cause of 401 errors.
Is checking aud enough to secure a role?
No. Check the subject too, so only the intended repository and trigger can assume the role.
Safeguard does not manage your cloud accounts. It scans your code and dependencies, applies pull request policies and gates, and automates compliance evidence. Free scan: gold.safeguard.sh/scan.
Sources
- GitLab Docs: ID token authentication
- GitHub Docs: OIDC in Amazon Web Services
- Microsoft Learn: Create a trust relationship between an app and an external identity provider
Last reviewed: 19 October 2026.
