> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/harness-platform/use-harness-platform/pipelines/workload-identity/token-claims-reference.md). # Token claims reference Token Claims Reference Tokens carry execution context claims that identify precisely which workload requested the token. This allows a relying party to scope permissions narrowly. For example, granting access only to a specific environment or step rather than to all Harness workloads in an account. ## Standard OIDC claims Every token carries the registered claims that the OIDC specification defines. A relying party validates these before it reads any execution context claim. | Claim | Description | | ----- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `iss` | Issuer. The Harness OIDC issuer URL for your account. A relying party accepts a token only when this value matches the issuer it trusts. Go to [Configure OIDC discovery URL in your provider](/harness-platform/use-harness-platform/pipelines/workload-identity/configure-oidc-url.md) for more information on constructing this value. | | `sub` | Subject. Identifies the workload that requested the token, and is the claim most trust policies match on. Go to [Subject templates](/harness-platform/use-harness-platform/pipelines/workload-identity/subject-templates.md) for more information on controlling its format. | | `aud` | Audience. The value you set in the `audience` field on the identity, such as `sts.amazonaws.com`. A relying party rejects a token minted for a different audience. | | `iat` | Issued at. The Unix timestamp when Harness issued the token. | | `exp` | Expiration. The Unix timestamp after which a relying party rejects the token. Harness issues short-lived tokens, so this value is close to `iat`. | | `nbf` | Not before. The Unix timestamp before which the token is not valid. A relying party rejects the token if it is presented earlier. | | `jti` | JWT ID. A unique identifier for the individual token. A relying party uses it to detect a replayed token, and you use it to correlate a token with an entry in an audit log. | Harness signs tokens with `RS256`. The token header carries a `kid` value that identifies which JWKS key verifies the signature. ## Execution context claims These claims describe the pipeline execution that requested the token. Harness generates every value from the server-side execution context, so a workload cannot set or override them. | Claim | Description | When it is present | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------- | | `account_id` | The Harness account that owns the pipeline. | Always. | | `org_id` | The organization that owns the pipeline. | When the pipeline is at organization or project scope. | | `project_id` | The project that owns the pipeline. | When the pipeline is at project scope. | | `pipeline_id` | The identifier of the pipeline that is running. | Always. | | `stage_id` | The identifier of the stage that contains the step. | Always. | | `stage_type` | The type of the stage that contains the step, such as a deployment stage. | Always. | | `step_id` | The identifier of the step that requested the token, which is the workload itself. | Always, because identities are step-scoped in this release. | | `step_type` | The type of the step that requested the token, such as a Shell Script step. | Always. | | `execution_id` | The identifier of the individual pipeline execution. Use this claim to correlate a token with one execution during an audit. | Always. | | `environment_id` | The Continuous Delivery environment being deployed to. | Only for a step in a CD stage. | | `environment_type` | The type of the environment, such as production or pre-production. Use this claim to write one trust policy that separates production access from non-production access. | Only for a step in a CD stage. | | `service_id` | The Continuous Delivery service being deployed. | Only for a step in a CD stage. | | `infrastructure_id` | The infrastructure definition being deployed to. | Only for a step in a CD stage. | | `connector_id` | The connector in context for the step. | Only when the step runs with a connector in context. | | `connector_type` | The type of the connector in context, such as an AWS or GCP connector. | Only when the step runs with a connector in context. | | `triggered_by` | The identity that started the execution, such as the user or the trigger. Use this claim to separate access for scheduled or webhook-driven runs from manual runs. | Always. | ## Cloud context claims These claims describe the cloud resource the workload acts against, which lets a relying party scope a trust policy to one cloud account, project, or region rather than to every workload in your Harness account. | Claim | Description | When it is present | | --------------------- | ----------------------------------------------------------------- | ----------------------------------------------- | | `cloud_provider` | The cloud provider in context, such as AWS, GCP, or Azure. | Only when the workload runs with cloud context. | | `cloud_account` | The cloud provider account in context, such as an AWS account. | Only when the workload runs with cloud context. | | `cloud_project` | The cloud project in context, such as a GCP project. | Only when the workload runs with cloud context. | | `cloud_subscription` | The cloud subscription in context, such as an Azure subscription. | Only when the workload runs with cloud context. | | `cloud_region` | The cloud region in context. | Only when the workload runs with cloud context. | | `cloud_resource_type` | The type of cloud resource in context. | Only when the workload runs with cloud context. | A token carries only the claims that its execution context supplies. For example, a step in a CD stage carries the deployment claims for environment, service, and infrastructure, while a workload that runs outside a deployment omits them entirely. {% hint style="warning" %} Scope your relying party trust policy to the claims the workload actually carries. A policy that requires an absent claim, such as a condition on `environment_id` for a step that runs outside a CD stage, rejects every token that workload presents. {% endhint %} ## Custom claims You can add your own claims to a token with the `customClaims` field on the identity. Harness flattens these into top-level claims, so a relying party reads them in the same way it reads an execution context claim, and a subject template references them as placeholders. Custom claim values support Harness expressions, which Harness resolves before it generates the token. Go to [OIDC ID tokens for the Shell Script step](https://developer.harness.io/docs/continuous-delivery/x-platform-cd-features/cd-steps/utilities/shell-script-step#oidc-id-tokens-for-the-shell-script-step) for more information. {% hint style="warning" %} Do not use a custom claim as the sole basis for a trust decision when the value comes from an expression a pipeline author controls. Trust the execution context claims for identity, and treat custom claims as additional context. {% endhint %}