cloudidentitysecurity.com

# runs locally · nothing you paste leaves this page · rules checked 2026-11-10

OIDC trust checker

Describe the pipeline job (GitHub Actions, GitLab CI or HCP Terraform), paste the trust configuration, and see whether the cloud would accept the job's token.

token.claims — the job
token issuer
input

IDs: gh api repos/OWNER/REPO --jq '{repo_id: .id, owner_id: .owner.id}'

job context
sub format
Set automatically when you switch issuer or cloud; edit it if your pipeline requests a custom audience.
payload (what the issuer would send)# a subset of claims; some values are illustrative
trust config — the cloud
result
Loading the checker… If this message stays, JavaScript may be blocked; the checker needs it to run.
What does the checker do?
It builds the claims a pipeline job would carry, following each issuer's documented formats:[sources]
  • GitHub Actions: repo:OWNER/REPO:… or the immutable repo:OWNER@ID/REPO@ID:…, for a branch, tag, environment or pull request.
  • GitLab CI on GitLab.com: project_path:GROUP/PROJECT:ref_type:…:ref:…, or the ID-based project_id:… form a project can opt into.
  • HCP Terraform: organization:…:project:…:workspace:…:run_phase:plan|apply, plus the organization, project and workspace ID claims.
It then evaluates your configuration the way each cloud describes it:
  • AWS: Allow and Deny statements, the Federated principal, the action, and StringEquals, StringLike, their negated and case-insensitive forms, Null, ForAnyValue/ForAllValues and …IfExists.
  • Microsoft Entra: exact issuer, subject and audience matching for plain credentials, and eq/matches terms joined with and/or for flexible credentials.
  • Google Cloud: the attribute condition, with ==, !=, &&, ||, !, in and startsWith/endsWith/contains over assertion.*.
Next to the verdict it lists findings: trust on names or paths only, missing audience checks, wildcards that never match under StringEquals, organization- or group-wide patterns, ForAllValues in Allow statements, subject-format mismatches, and plan/apply coverage for HCP Terraform. It also writes a scoped configuration for the job you described.
What doesn't it check?
  • Whether the token's signature is valid or the OIDC provider exists in your account.
  • The role's permissions policy, service control policies, resource control policies or permission boundaries on AWS.
  • Google Cloud IAM bindings (principal or principalSet) and service account impersonation; the attribute condition is only the first gate.
  • Condition keys that don't come from the GitHub token (for example aws:SourceIp). These are listed and treated as satisfied.
  • Customized subject templates set with GitHub's include_claim_keys API. Paste decoded claims to test those.
  • GitLab Self-Managed, GitLab Dedicated and Terraform Enterprise presets. Paste decoded claims with your own iss; matching works, but findings are tuned for GitLab.com and HCP Terraform.
  • GitLab claims beyond the ones shown, and HCP Terraform module test tokens (their subject has no workspace).
The immutable format for tags, environments and pull requests is built by analogy with the branch example GitHub documents. Confirm against your own repository's subject before you rely on it.
Is anything sent to a server?
No. The page loads once and all checks run in JavaScript in your browser. Nothing you type is stored or transmitted. Paste decoded claims only; never paste a raw token, since it works as a credential until it expires.
Sources the rules follow
# rules last checked against these pages on November 10, 2026