Yes, treat it as a short lived secret. A CI OIDC token proves a job's identity, and anyone holding a valid one can exchange it for cloud credentials until it expires. Keep it out of logs, limit its audience, and rely on its short life as a backstop.
What the token is
An OIDC token from a CI platform is a signed JSON web token. It states who issued it, who it is for and what job requested it. Your cloud verifies the signature and checks the claims against a trust policy. If they match, it hands back temporary credentials.
The token is a bearer credential. Nothing in it binds it to the machine that requested it. If another party gets the string while it is valid, the cloud has no way to tell the difference unless your trust policy narrows what the token can do.
How long does it live?
GitLab's documentation says the expiry is set to the job's timeout if one is specified, or 5 minutes if not. Tokens are signed with RS256. That is short, but jobs often run longer than five minutes after the exchange, and the credentials you get back have their own lifetime, set by the cloud role and request. On AWS, a role session defaults to one hour and can be raised up to 12 hours by role setting, except when roles are chained, which caps at one hour.
So there are two clocks: the token's life, which limits how long it can be exchanged, and the credentials' life, which limits what the exchange gives.
Handling rules
- Do not print it. Avoid debug output that echoes environment variables. Many CI systems mask known secrets, but a token minted at runtime may not be masked unless you register it.
- Request only what you need. In GitHub Actions, the
id-token: writepermission is needed to request a token, and GitHub says it does not grant write access to other resources. Set it at job level, only on jobs that need it. - Use a distinct audience per service. GitLab notes that doing so limits how many services a stolen token can reach.
- Do not pass it to third party steps that do not need it. A third party action running in the same job can read what the job can read. GitHub advises pinning actions to a full commit SHA and confirming the SHA belongs to the action's repository, not a fork.
- Do not upload it as an artifact or cache it.
- Prefer tokens minted inside the job over tokens stored anywhere. A stored token is a long term secret in disguise.
What a stolen token can and cannot do
If an attacker obtains a token from a job log within its lifetime, they can try to assume the role. That works only if the trust policy accepts the token's claims. This is why exact subject and audience conditions matter. A token from a pull request job cannot assume a role trusted only for an environment subject. A token with an audience for service A is rejected by service B.
The role's permissions then decide the damage. A read only role limits it. A deploy role with a narrow scope limits it differently.
Detection
CloudTrail records the web identity role assumption, including identity provider information, per AWS documentation. Alert on assumptions of your deploy role from unexpected sources or at odd hours. A role session name that includes the run ID lets you check each assumption against a real pipeline run.
Quick check
Can I log the token for debugging?
Avoid it. Anyone who can read the log can try to use the token until it expires. Decode claims in a throwaway job instead.
Does a short token life make exact trust conditions unnecessary?
No. Five minutes is plenty of time to misuse a token. Conditions on subject and audience are the real control.
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
- GitHub Docs: Secure use reference
- AWS IAM User Guide: Roles terms and concepts
- AWS IAM User Guide: Logging IAM and AWS STS API calls with AWS CloudTrail
Last reviewed: 19 October 2026.
