--- title: "Using OpenID Connect tokens in jobs" description: "Learn how to use OpenID Connect ID tokens for access to compatible cloud services." doc_version: "unversioned" last_updated: "2026-05-22" --- > For the complete documentation index, see [llms.txt](https://circleci.com/docs/llms.txt) # Using OpenID Connect tokens in jobs CircleCI provides OpenID Connect ID (OIDC) tokens in environment variables. Jobs can be configured to use these OIDC tokens to access compatible cloud services without long-lived credentials being stored in CircleCI. Some advantages to using OIDC over using static credentials: * **Improved security**: By using OIDC authentication, storing credentials directly in your CircleCI configuration or environment variables is avoided, reducing the risk of exposure. * **Simplified credential management**: OIDC allows CircleCI to automatically manage the authentication process, eliminating the need to manually manage and rotate credentials. * **Fine-grained access control**: By associating a cloud provider role with OIDC authentication, exact permissions granted to CircleCI can be controlled, ensuring a least-privilege approach. ## OpenID Connect tokens CircleCI OpenID Connect ID tokens are available in the following environment variables: * `$CIRCLE_OIDC_TOKEN` * `$CIRCLE_OIDC_TOKEN_V2` - This token includes a different `sub` claim format to include a reference to the source of the change that triggered the job. See [OpenID Connect ID tokens format](#format-of-the-openid-connect-id-token) for full details on the Claims used in each token. **What about forks?** OIDC tokens will only be generated for forked builds if the **Pass secrets to builds from forked pull requests** setting is enabled. Find this option at **Project settings** > **Advanced**. See [OIDC in open source projects](#oidc-in-open-source-projects). ## Set up cloud provider authentication Before your cloud service will accept CircleCI’s OIDC tokens, you need to configure it to trust CircleCI as an identity provider. This tells your cloud service that tokens issued by CircleCI for your organization are legitimate and can be accepted. An identity provider is a configuration in your cloud service that defines a trusted source of authentication tokens. You can use CircleCI’s OIDC tokens with multiple cloud services. The following sections describe how to configure CircleCI jobs to authenticate with a cloud provider. Follow steps for your cloud provider, either AWS or GCP. ## AWS The following instructions cover the following: * A one-time configuration of your AWS account to trust CircleCI’s OIDC tokens. * Running a job that uses the OIDC token to interact with AWS. See the [Pull an Image From AWS ECR With OIDC](https://circleci.com/docs/guides/permissions-authentication/pull-an-image-from-aws-ecr-with-oidc/) how-to guide after following this setup section. ### Prerequisites You will need to have the following to continue your AWS OIDC setup: * A CircleCI account. You must be a member of an organization. See [Sign up and Try CircleCI](https://circleci.com/docs/guides/getting-started/first-steps/) for more information. * A project set up that you want to configure to use OIDC. * An AWS account with the necessary permissions to create an IAM identity provider and role. ### 1\. Set up identity provider in AWS In this step you will allow your AWS account to trust CircleCI’s OpenID Connect tokens. Follow the steps in this section to create an Identity and Access Management (IAM) identity provider, and an IAM role in AWS. Creating the identity provider is a one-time configuration to get set up. To create your identity provider you will need to know your [OpenID Provider](https://openid.net/specs/openid-connect-core-1_0.html#Terminology), which is unique to your organization. The OpenID Provider URL is `https://oidc.circleci.com/org/`, where `organization_id` is your unique organization identifier. To find your organization ID and organization slug, select **Org** in the CircleCI web app sidebar to open your organization settings page. The organization ID is available to copy from the org settings overview page. > **Image:** screenshot showing where to find your organization ID Figure 1. Organization ID available in organization settings The default OpenID Connect ID tokens issued by CircleCI have a fixed audience (see `aud` in [the table below](#format-of-the-openid-connect-id-token)). This audience is also the organization ID. To generate tokens with _custom_ audience claims, see the [OIDC Tokens With Custom Claims](https://circleci.com/docs/guides/permissions-authentication/oidc-tokens-with-custom-claims/) page. Visit the [Creating OpenID Connect (OIDC) identity providers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) page of the AWS docs and follow the instructions. Multiple setup options are available including using the management console or CLI. You will need to provide the following: * **OpenID Provider URL**: Enter `https://oidc.circleci.com/org/`, where `your-organization-id` is the ID of your CircleCI organization. * **Audience**: Enter your organization ID. ### 2\. Assign a role to your identity provider Now you have your identity provider set up, you can assign roles to it and decide how to manage the associated role(s). You can update the role permissions using policies to fit your use cases. You can also create roles specific to each use. Once you have created your identity provider, a banner appears at the top of the AWS console with the option to **Assign role**. Select this button to create a new role, or visit the [Creating a role for web identity or OIDC](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html#idp_oidc_Create) section of the AWS docs and follow the steps there. You will need to select the following: * The **identity provider** that you just created. * For **Audience**, choose the only option, which is your organization ID that you entered when creating the identity provider. * On the **Add Permissions** page you can specify what your CircleCI jobs _can_ and _cannot_ do. Choose only permissions that your job will need. Choosing minimal permissions is an [AWS best practice](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege). You can also write your own policies to lock down permissions to exactly what you need for a specific use case. AWS STS supports a dedicated [condition key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-wif) for CircleCI’s `oidc.circleci.com/project-id` claim. Use this key in your role’s trust policy to restrict which CircleCI projects can assume the role. See [Limit role access based on project](#limit-role-access-based-on-project) for sample policies. ### 3\. Add AWS to your CircleCI configuration file Now that you have set up your trusted identity provider and IAM role, you are ready to configure a CircleCI job that authenticates with AWS using OIDC. Use CircleCI’s [AWS CLI orb](https://circleci.com/developer/orbs/orb/circleci/aws-cli) to generate temporary keys and configure a profile that uses OIDC. When using OIDC authentication, you **do not need to manually create or store AWS credentials files** in CircleCI. The `aws-cli/setup` command automatically handles the credential generation and configuration using the OIDC token. Orbs are reusable packages of YAML configuration that condense repeated pieces of configuration into a single line of code. The AWS CLI orb enables you to generate a temporary session token, AWS Access Key ID, and AWS secret access key with a single command in your configuration. 1. In your `.circleci/config`, import the `aws-cli` orb. ```yaml version: 2.1 orbs: aws-cli: circleci/aws-cli@5.4.1 ``` 2. Configure your job to run the `aws-cli/setup` command before interacting with any AWS services. Provide the `aws-cli/setup` command with the `role_arn` associated with the role you have created in the step above along with your `region`, which is your AWS region. ```yaml jobs: aws-example: environment: AWS_REGION: us-west-1 docker: - image: cimg/aws:2025.01 steps: - checkout # run the aws-cli/setup command from the orb - aws-cli/setup: role_arn: "arn:aws:iam::123456789012:role/OIDC-ROLE" region: ${AWS_REGION} # optional parameters profile_name: "OIDC-PROFILE" role_session_name: ${CIRCLE_JOB} session_duration: "1800" ``` You can optionally provide a `profile_name`, `role_session_name`, and `session_duration`. If you provide a `profile_name`, the temporary keys and token will be configured to that specific profile. You must use that same `profile_name` with the rest of your AWS commands. If a `profile_name` is not provided, the keys and token will be configured to the default profile. If you do not provide a `role_session_name` or `session_duration`, their default values are `${CIRCLE_JOB}` (your job’s name) and 3600 seconds respectively. Below is an example of a complete configuration with a job that configures a profile with OIDC and uses it to log into AWS ECR. The same profile can be used to run other AWS commands, such as S3, EKS, ECS, and more, as long as the `role_arn` has been configured with appropriate permissions. ```yaml version: 2.1 orbs: aws-cli: circleci/aws-cli@5.4.1 jobs: aws-example: environment: AWS_REGION: us-west-1 docker: - image: cimg/aws:2025.01 steps: - checkout # run the aws-cli/setup command from the orb - aws-cli/setup: role_arn: "arn:aws:iam::123456789012:role/OIDC-ROLE" region: ${AWS_REGION} # optional parameters profile_name: "OIDC-PROFILE" role_session_name: ${CIRCLE_JOB} session_duration: "1800" - run: name: Log-into-AWS-ECR command: | # must use same profile specified in the step above aws ecr get-login-password --profile "OIDC-PROFILE" workflows: OIDC-with-AWS: jobs: - aws-example: context: aws ``` ### Advanced usage You can take advantage of the format of the claims in CircleCI’s [OIDC tokens](#format-of-the-openid-connect-id-token) to limit what your CircleCI jobs can do in AWS. #### Limit role access based on project If a project needs to access only certain AWS resources, you can restrict your IAM role so that only CircleCI jobs in that project can assume that role. To do this, edit your IAM role’s trust policy so that only an OIDC token from your chosen project can assume that role. The trust policy determines under what conditions the role can be assumed. 1. Go to an individual project’s page in the [CircleCI web app](https://app.circleci.com/) and navigate to menu:Project Settings \[Overview\] to find your Project ID. 2. Add the following condition to your role’s trust policy, so that only jobs in your chosen project can assume that role. Replace `` with your CircleCI organization ID and `` with your CircleCI project ID. See [How to Find IDs](https://circleci.com/docs/guides/toolkit/how-to-find-ids/) for help. **Option 1: Using the CircleCI project-id claim (recommended)** AWS STS maps CircleCI’s `oidc.circleci.com/project-id` OIDC claim to a [Web Identity Federation condition key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-wif). This key identifies the CircleCI project in which the job is running. Its value is a string containing a UUID that uniquely identifies the CircleCI project. Use this condition key with string operators in your trust policy to restrict access to specific CircleCI projects. ```yaml { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.circleci.com/org/" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "oidc.circleci.com/org/:aud": "sts.amazonaws.com", "oidc.circleci.com/org/:oidc.circleci.com/project-id": "" } } } ] } ``` The `oidc.circleci.com/project-id` condition key is evaluated during `sts:AssumeRoleWithWebIdentity` and is not available as a session tag after the role is assumed. **Option 2: Using the sub claim** Update trust policy to restrict access to specific project ```yaml "StringLike": { "oidc.circleci.com/org/:sub": "org//project//user/*" } ``` This uses [StringLike](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_String) to match the `sub` claim of CircleCI’s OIDC token in your chosen project. Now, jobs in your other projects cannot assume this role. #### Limit role access based on branch You can also restrict access to specific branches. The following is an example of a trust policy with restrictions. The `AssumeRoleWithWebIdentity` action is restricted to pipelines running only on the `main` branch in the `my-org` GitHub organization and the CircleCI organization with the ID `organization_id`. Note that the `sub` claim uses the `$CIRCLE_OIDC_TOKEN_V2` format. ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.circleci.com/org/" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringLike": { "oidc.circleci.com/org/:sub": "org//project/*/user/*/vcs-origin/github.com/my-org/*/vcs-ref/refs/heads/main" } } } ] } ``` ## Google Cloud Platform The following instructions cover: * A one-time configuration of your GCP settings to trust CircleCI’s OIDC tokens. * Running a job that uses the OIDC token to interact with GCP. The Google Cloud CLI reads your configuration file to authenticate. You can read about external identity providers on [Google Cloud’s docs](https://cloud.google.com/iam/docs/configuring-workload-identity-federation#oidc). ### Prerequisites You will need to have the following to continue your GCP OIDC setup: * A CircleCI account where you are a member of an organization. See [Sign up and Try CircleCI](https://circleci.com/docs/guides/getting-started/first-steps/) for more information. * A project set up that you want to configure to use OIDC. * A GCP account with the necessary permissions to create a Workload Identity pool and provider. ### 1\. Set up GCP The steps in this section are based on Google Cloud Platform’s [Configuring Workload Identity federation](https://cloud.google.com/iam/docs/configuring-workload-identity-federation#oidc) documentation. To create your identity provider you will need to know your [OpenID Provider](https://openid.net/specs/openid-connect-core-1_0.html#Terminology), which is unique to your organization. The OpenID Provider URL is `https://oidc.circleci.com/org/`, where `organization_id` is your unique organization identifier. You can find your CircleCI organization ID by navigating to **Org**  **Overview** in the [CircleCI web app](https://app.circleci.com/). The default OpenID Connect ID tokens issued by CircleCI have a fixed audience (see `aud` in [the table below](#format-of-the-openid-connect-id-token)). This audience is also the organization ID. To generate tokens with _custom_ audience claims, see the [OIDC Tokens With Custom Claims](https://circleci.com/docs/guides/permissions-authentication/oidc-tokens-with-custom-claims/) page. ### 2\. Configure GCP Workload Identity Federation GCP Workload Identity Federation is a feature that allows you to use CircleCI’s OIDC tokens to authenticate with GCP. It allows applications outside Google Cloud to access Google Cloud resources without storing service account credentials. You can use Identity and Access Management (IAM) to grant access to specific Google Cloud resources. In the GCP web UI, follow the steps to add CircleCI as an external identity provider: 1. Navigate to the **IAM & Admin panel**. 2. On the side panel, navigate to **Workload Identity Federation**. 3. Select **Add Provider**. 4. Select **OpenID Connect (OIDC)** from the "Select a provider" dropdown and select **Save**. 5. Fill out the **Provider details** form. * Select **Allowed audiences** since the `aud` claim in the JSON Web Token is a UUID. Set the `audience` to your CircleCI organization ID. * The issuer is `https://oidc.circleci.com/org/`, where `organization_id` is your CircleCI organization ID. 6. Select **Continue** to configure provider attributes. Configuring the provider attributes provides an opportunity to map claims in CircleCI’s token to Google’s "understanding". Use this mapping: | `google.subject` | `assertion.sub` | | --- | --- | | `attribute.org_id` | `assertion.aud` | | `attribute.project` | `assertion['oidc.circleci.com/project-id']` | 7. Navigate to **Service Account** in the IAM & Admin Panel to create a service account, and give appropriate permission. 8. Navigate back to **Workload Identity Federation** and select the provider from the table. 9. Select **Grant access**. 10. A modal will open and you will select the service account you created from the dropdown. The token will impersonate this account and receive all its associated permissions. 11. Under **Select principals**, you can add conditions, or leave the default. 12. Select **Save**. A pop-up will appear with options to configure and **download** the configuration file. You can also download this file later by navigating to **Connected Service Accounts**. ### 3\. Configure your CircleCI pipeline You have two options for configuring your CircleCI pipeline to use the GCP configuration file. You can download the file once and commit it to your repository. Alternatively, you can generate the file dynamically in your CircleCI pipeline. **Dynamic configuration** generation is more secure (no secrets in repo), but more complex to set up. Choosing the **file download** option is simpler to set up. However, the config file will be in your repository and visible to anyone with access. If you choose to generate the configuration file dynamically in your pipeline, you can use the GCP CLI. The following example is an excerpt from the full configuration file below: Use CLI to generate the GCP configuration file dynamically ```shell gcloud iam workload-identity-pools create-cred-config \ "${GCP_WORKLOAD_IDENTITY_POOL_AUDIENCE}" \ --output-file="${GCP_CREDENTIAL_CONFIGURATION_FILE}" \ --service-account="${GCP_SERVICE_ACCOUNT_EMAIL}" \ --credential-source-file="${GCP_CREDENTIAL_SOURCE_FILE}" ``` Download the configuration file once and commit this to your repository. You can name the file anything you like but best practice is to give it a descriptive name, for example, `gcp-config-dev.json`. You will reference this file in your CircleCI configuration. An example of the configuration file is shown below along with descriptions for some fields. | **Placeholder** | **Description** | | --- | --- | | `project_number` | The unique identifying number generated for your project. | | `pool_id` | An ID that references the Workload Identity pool, for example `circleci_oidc`. | | `provider_id` | An ID that references the Workload Identity pool provider, for example, `circleci`. | ```json { "type": "external_account", "audience": "//iam.googleapis.com/projects//locations/global/workloadIdentityPools//providers/", "subject_token_type": "urn:ietf:params:oauth:token-type:jwt", "token_url": "https://sts.googleapis.com/v1/token", "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/circleci-test@incubator-344312.iam.gserviceaccount.com:generateAccessToken", "credential_source": { "file": "CIRCLE_OIDC_TOKEN_FILE", "format": { "type": "text" } } } ``` In this configuration, `credential_source` will attempt to find your identity token in the `CIRCLE_OIDC_TOKEN_FILE` file. The file name can be anything, as long as it matches the file name specified in `credential_source.file` in your downloaded configuration file. If your token comes from an API response, it might be useful to set up the configuration to read a JSON file. In this case, the `type` will need to be set to `json` and you will need to provide a valid `path`, for example, `response.id_token`. ```json "credential_source": { "file": "CIRCLE_OIDC_TOKEN_FILE", "format": { "type": "json", "path": "response.id_token" } } ``` You will need to write one of CircleCI’s OIDC tokens to a file in your job. You can use either $CIRCLE\_OIDC\_TOKEN or $CIRCLE\_OIDC\_TOKEN\_V2. The V2 token includes additional VCS information (repository and branch) which allows for more granular access control in GCP. See [OpenID Connect ID tokens format](#format-of-the-openid-connect-id-token) for details on the differences. For example: Write the OIDC token to a file ```shell echo $CIRCLE_OIDC_TOKEN >> CIRCLE_OIDC_TOKEN_FILE ``` Add the following environment variables to a context. You will use this context in your CircleCI configuration to give your pipeline access to securely access the environment variables. See the [Contexts](https://circleci.com/docs/guides/security/contexts/) page for more information. | **Context var name** | **Example value** | **Notes** | | --- | --- | --- | | GCP\_PROJECT\_ID | `123456789012` | [GCP project number](https://cloud.google.com/resource-manager/docs/creating-managing-projects#before_you_begin) | | GCP\_WIP\_ID | `myworkloadpoolid` | [Workload Identity pool ID](https://cloud.google.com/iam/docs/manage-workload-identity-pools-providers#pools) | | GCP\_WIP\_PROVIDER\_ID | `myproviderid` | [Workload Identity pool provider name](https://cloud.google.com/iam/docs/manage-workload-identity-pools-providers#manage-providers) | | GCP\_SERVICE\_ACCOUNT\_EMAIL | `myserviceacct@myproject.iam.gserviceaccount.com` | [User-managed Service Accounts](https://cloud.google.com/iam/docs/service-accounts#user-managed) | Below is a full example configuration adding GCP to a job and demonstrating that authentication works with the `gcp-oidc-authenticate` command. This example uses the [`circleci/gcp-cli` orb](https://circleci.com/developer/orbs/orb/circleci/gcp-cli). Note that you can enable the use of OIDC token when using `circleci/gcp-cli` orb version 3.0.0 or later. Full example configuration using the `gcp-cli` orb for OIDC authentication ```yaml version: 2.1 orbs: gcp-cli: circleci/gcp-cli@2.4.1 commands: gcp-oidc-generate-cred-config-file: description: "Authenticate with GCP using a CircleCI OIDC token." parameters: project_id: type: env_var_name default: GCP_PROJECT_ID workload_identity_pool_id: type: env_var_name default: GCP_WIP_ID workload_identity_pool_provider_id: type: env_var_name default: GCP_WIP_PROVIDER_ID service_account_email: type: env_var_name default: GCP_SERVICE_ACCOUNT_EMAIL gcp_cred_config_file_path: type: string default: /home/circleci/gcp_cred_config.json oidc_token_file_path: type: string default: /home/circleci/oidc_token.json steps: - run: command: | # Store OIDC token in temp file echo $CIRCLE_OIDC_TOKEN > << parameters.oidc_token_file_path >> # Create a credential configuration for the generated OIDC ID Token gcloud iam workload-identity-pools create-cred-config \ "projects/${<< parameters.project_id >>}/locations/global/workloadIdentityPools/${<< parameters.workload_identity_pool_id >>}/providers/${<< parameters.workload_identity_pool_provider_id >>}"\ --output-file="<< parameters.gcp_cred_config_file_path >>" \ --service-account="${<< parameters.service_account_email >>}" \ --credential-source-file=<< parameters.oidc_token_file_path >> gcp-oidc-authenticate: description: "Authenticate with GCP using a GCP credentials file." parameters: gcp_cred_config_file_path: type: string default: /home/circleci/gcp_cred_config.json steps: - run: command: | # Configure gcloud to leverage the generated credential configuration gcloud auth login --brief --cred-file "<< parameters.gcp_cred_config_file_path >>" # Configure ADC echo "export GOOGLE_APPLICATION_CREDENTIALS='<< parameters.gcp_cred_config_file_path >>'" | tee -a "$BASH_ENV" jobs: gcp-oidc-defaults: executor: gcp-cli/default steps: - gcp-cli/install - gcp-oidc-generate-cred-config-file - gcp-oidc-authenticate - run: name: Verify that gcloud is authenticated environment: GCP_SERVICE_ACCOUNT_EMAIL: jennings-oidc-test@makoto-workbench.iam.gserviceaccount.com command: gcloud iam service-accounts get-iam-policy "${GCP_SERVICE_ACCOUNT_EMAIL}" workflows: main: jobs: - gcp-oidc-defaults: name: Generate Creds File and Authenticate context: - gcp-oidc-dev ``` You have the ability to use multiple service accounts from the _same_ GCP project, or multiple service accounts from _multiple_ GCP projects. You can read about these methods and find an example in CircleCI’s [example repository](https://github.com/jtreutel/circleci-gcp-oidc-test#usage). ## OpenID Connect ID tokens format CircleCI’s OIDC tokens contain the following standard [claims](https://openid.net/specs/openid-connect-core-1_0.html#IDToken):
ClaimsDescription
issThe issuer, specific to the CircleCI organization in which the job is being run. Its value is "https://oidc.circleci.com/org/<organization_id>", where organization_id is a UUID identifying the current job’s project’s organization. It is possible to generate a token manually with a root issuer using the --root-issuer flag. See OIDC Tokens With Custom Claims for more information.
sub

The subject. This identifies who is running the CircleCI job and where. $CIRCLE_OIDC_TOKEN_V2 also includes information about the source of change.

For $CIRCLE_OIDC_TOKEN its value is:

"org/<organization_id>/project/<project-id>/user/<user_id>", a string, where organization_id, project-id, and user_id are UUIDs that identify the CircleCI organization, project, and user, respectively. The user is the CircleCI user that caused this job to run.

For $CIRCLE_OIDC_TOKEN_V2 its value depends on the trigger type:

If the trigger is a Custom Webhook:

"org/<organization_id>/project/<project-id>/user/<user_id>"

A string in which organization_id, project-id, and user_id are UUIDs that identify the CircleCI organization, project, and user, respectively. The user is the CircleCI user that caused this job to run.

All other trigger types:

"org/<organization_id>/project/<project-id>/user/<user_id>/vcs-origin/<vcs_origin>/vcs-ref/<vcs_ref>"

A string in which organization_id, project-id, and user_id are UUIDs that identify the CircleCI organization, project, and user, respectively. The user is the CircleCI user that caused this job to run. vcs_origin and vcs_ref are strings that identify the repository URL and reference to the change that caused the job to run.

audThe audience. By default, this is ORGANIZATION_ID, a string containing a UUID that identifies the job’s project’s organization. To customize the audience you can generate an OIDC token with a custom audience. See OIDC Tokens With Custom Claims for more information.
iatThe time of issuance. This is the time the token was created, which is shortly before the job starts.
expThe expiration time. Its value is one hour after the time of issuance.
CircleCI’s OpenID Connect ID tokens also contain some [additional claims](https://openid.net/specs/openid-connect-core-1_0.html#AdditionalClaims) with extra metadata about the job: | Additional claims | Metadata | | --- | --- | | `oidc.circleci.com/context-ids` | An array of strings containing UUIDs that identify the context(s) used in the job. | | `oidc.circleci.com/job-id` | The unique identifier for the job. Its value is a string containing a UUID identifying the CircleCI job. | | `oidc.circleci.com/org-id` | The unique identifier for the organization. Its value is a string containing a UUID identifying the CircleCI organization. | | `oidc.circleci.com/pipeline-definition-id` | The unique identifier for the pipeline definition that created the pipeline running the workflow. The value is a string containing a UUID identifying the CircleCI pipeline definition. Pipeline definitions are found in your project settings under Project Setup. | | `oidc.circleci.com/pipeline-id` | The unique identifier for the pipeline that triggered this job. Its value is a string containing a UUID identifying the CircleCI pipeline. | | `oidc.circleci.com/project-id` | The CircleCI project ID. Its value is a string containing a UUID that uniquely identifies the CircleCI project. Use this claim to restrict access to specific CircleCI projects. In AWS, this claim maps to a [Web Identity Federation condition key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-wif) that works with string operators. | | `oidc.circleci.com/ssh-rerun` | A boolean indicating if the CI job is started using the SSH rerun feature. | | `oidc.circleci.com/vcs-origin` | The URL of the repository that triggered the pipeline. Its value is a string similar to `github.com/organization-123/repo-1`. This is not present for pipelines triggered by custom webhooks. | | `oidc.circleci.com/vcs-ref` | The reference to the change that triggered the pipeline. Its value is a string similar to `refs/heads/main`. This is not present for pipelines triggered by custom webhooks. | | `oidc.circleci.com/workflow-id` | The unique identifier for the workflow running the job. Its value is a string containing a UUID identifying the CircleCI workflow. | ## OIDC in open source projects OIDC tokens will only be generated for forked builds if the **Pass secrets to builds from forked pull requests** setting is enabled. Find this option at **Project settings** > **Advanced**. If you allow OIDC tokens to be generated for forks, you **must** check the `oidc.circleci.com/vcs-origin` claims in your policies to prevent forked builds from accessing unauthorized resources. For more information about building open source projects on CircleCI, see the [Build Open Source Projects](https://circleci.com/docs/guides/integration/oss/) page. ## OIDC on CircleCI Server OIDC is supported from server v4.4+. However, OIDC is **not** supported if your server installation is in an air-gapped environment. ## Next steps * [OpenID Connect Tokens With Custom Claims](https://circleci.com/docs/guides/permissions-authentication/oidc-tokens-with-custom-claims/)