{% data variables.product.prodname_actions %} workflows are often designed to access a cloud provider (such as AWS, Azure, GCP, HashiCorp Vault, and others) in order to deploy software or use the cloud's services. Before the workflow can access these resources, it will supply credentials, such as a password or token, to the cloud provider. These credentials are usually stored as a secret in {% data variables.product.prodname_dotcom %}, and the workflow presents this secret to the cloud provider every time it runs.

However, using hardcoded secrets requires you to create credentials in the cloud provider and then duplicate them in {% data variables.product.prodname_dotcom %} as a secret.

After you have established a trust connection with a cloud provider that supports OIDC, you can configure your workflow to request a short-lived access token directly from the cloud provider.

By updating your workflows to use OIDC tokens, you can adopt the following good security practices:

• No cloud secrets: You won't need to duplicate your cloud credentials as long-lived {% data variables.product.github %} secrets. Instead, you can configure the OIDC trust on your cloud provider, and then update your workflows to request a short-lived access token from the cloud provider through OIDC.
• Authentication and authorization management: You have more granular control over how workflows can use credentials, using your cloud provider's authentication (authN) and authorization (authZ) tools to control access to cloud resources.
• Rotating credentials: With OIDC, your cloud provider issues a short-lived access token that is only valid for a single job, and then automatically expires.

The following diagram gives an overview of how {% data variables.product.github %}'s OIDC provider integrates with your workflows and cloud provider:

1. You establish an OIDC trust relationship in the cloud provider, allowing specific {% data variables.product.github %} workflows to request cloud access tokens on behalf of a defined cloud role.
2. Every time your job runs, {% data variables.product.prodname_dotcom %}'s OIDC provider auto-generates an OIDC token. This token contains multiple claims to establish a security-hardened and verifiable identity about the specific workflow that is trying to authenticate.
3. A step or action in the workflow job can request a token from {% data variables.product.github %}’s OIDC provider, which can then be presented to the cloud provider as proof of the workflow’s identity.
4. Once the cloud provider successfully validates the claims presented in the token, it then provides a short-lived cloud access token that is available only for the duration of the job.

Each job requests an OIDC token from {% data variables.product.prodname_dotcom %}'s OIDC provider, which responds with an automatically generated JSON web token (JWT) that is unique for each workflow job where it is generated. When the job runs, the OIDC token is presented to the cloud provider. To validate the token, the cloud provider checks if the OIDC token's subject and other claims are a match for the conditions that were preconfigured on the cloud role's OIDC trust definition.

The following example OIDC token uses a subject (sub) that references a job environment named prod in the octo-org/octo-repo repository.

{
  "typ": "JWT",
  "alg": "RS256",
  "x5t": "example-thumbprint",
  "kid": "example-key-id"
}
{
  "jti": "example-id",
  "sub": "repo:octo-org/octo-repo:environment:prod",
  "environment": "prod",
  "aud": "{% ifversion ghes %}https://HOSTNAME{% else %}https://github.com{% endif %}/octo-org",
  "ref": "refs/heads/main",
  "sha": "example-sha",
  "repository": "octo-org/octo-repo",
  "repository_owner": "octo-org",
  "actor_id": "12",
  "repository_visibility": "private",
  "repository_id": "74",
  "repository_owner_id": "65",
  "run_id": "example-run-id",
  "run_number": "10",
  "run_attempt": "2",
  "runner_environment": "github-hosted",
  "actor": "octocat",
  "workflow": "example-workflow",
  "head_ref": "",
  "base_ref": "",
  "event_name": "workflow_dispatch",{% ifversion actions-OIDC-custom-claim-enterprise %}
  "enterprise": "avocado-corp",{% endif %}{% ifversion actions-OIDC-enterprise_id-claim %}
  "enterprise_id": "2",{% endif %}{% ifversion oidc-custom-properties %}
  "repo_property_workspace_id": "ws-abc123",{% endif %}
  "ref_type": "branch",
  "job_workflow_ref": "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main",
  "iss": "{% ifversion ghes %}https://HOSTNAME/_services/token{% else %}https://token.actions.githubusercontent.com{% endif %}",
  "nbf": 1632492967,
  "exp": 1632493867,
  "iat": 1632493567
}

{% ifversion ghec %}

To use OIDC in your workflows, you must establish a trust relationship between {% data variables.product.github %} and your cloud provider. This trust relationship ensures that only authorized workflows can request access tokens for your cloud resources.

Before granting an access token, your cloud provider checks that the subject and any other claims used to set conditions in its trust settings match those in the request's JSON Web Token (JWT). If the trust configuration matches, your cloud provider issues a temporary access token to the workflow.

For steps and syntax for configuring OIDC trust and setting conditions for cloud providers, see AUTOTITLE.

If you are part of an enterprise that uses {% data variables.enterprise.data_residency %} and you're setting up OIDC on {% data variables.enterprise.data_residency_site %}, you must substitute certain values while configuring OIDC.

For more information, see AUTOTITLE.

{% endif %}

Custom actions use the getIDToken() method from the Actions toolkit or a curl command to authenticate using OIDC.

For more information, see AUTOTITLE.

{% data variables.product.prodname_actions %} workflows can use OIDC tokens instead of secrets to authenticate with cloud providers. Many popular cloud providers offer official login actions that simplify the process of using OIDC in your workflows. For more information about updating your workflows with specific cloud providers, see AUTOTITLE.

{% ifversion oidc-custom-properties %}

Organization and enterprise admins can include repository custom properties as claims in OIDC tokens. This enables attribute-based access control (ABAC) policies in your cloud provider, artifact registry, or secrets manager that are driven by repository metadata rather than hard-coded allow lists.

The end-to-end flow for using custom properties as OIDC claims is as follows:

1. Define custom properties. An organization or enterprise admin creates custom properties (for example, business_unit, data_classification, or environment_tier) and assigns values to repositories. For more information, see AUTOTITLE and AUTOTITLE.
2. Enable properties in OIDC tokens. An organization or enterprise admin selects which custom properties should be included in OIDC tokens, using the settings UI or the REST API.
3. Claims appear automatically. Every workflow run in a repository that has a value set for an enabled property will include that value in its OIDC token, prefixed with repo_property_. No workflow-level configuration changes are required.
4. Update cloud trust policies. You update your cloud provider's trust conditions to evaluate the new repo_property_* claims, enabling fine-grained, attribute-based access decisions.

Because this builds on {% data variables.product.prodname_dotcom %}'s existing OIDC short-lived credential model, no long-lived secrets are required, and every token is scoped, auditable, and automatically rotated per workflow run.

• Custom properties must already be defined at the organization or enterprise level. For more information, see AUTOTITLE.
• You must be an organization admin or enterprise admin.

To include a custom property in OIDC tokens, use the REST API or the settings UI for your organization or enterprise.

• Using the settings UI: Navigate to your organization or enterprise's Actions OIDC settings page to view and manage which custom properties are included in OIDC tokens.

• Using the REST API: Send a POST request to the /orgs/{org}/actions/oidc/customization/properties/repo endpoint to add a custom property to the OIDC token claims for your organization. For request parameters and full details, see the REST API documentation for managing OIDC custom properties: AUTOTITLE.

The following example shows an OIDC token that includes two custom properties: a single-select property business_unit and a string property workspace_id. Each custom property appears in the token with the repo_property_ prefix.

{
  "sub": "repo:my-org/my-repo:ref:refs/heads/main",
  "aud": "https://github.com/my-org",
  "repository": "my-org/my-repo",
  "repository_owner": "my-org",
  "ref": "refs/heads/main",
  "repo_property_business_unit": "payments",
  "repo_property_workspace_id": "ws-abc123"
}

You can use the repo_property_* claims in your cloud provider's trust conditions to create flexible, attribute-based access control policies. For more information about the claim format, supported property types, and limits, see AUTOTITLE.

{% endif %}

{% data variables.product.prodname_dependabot %} can use OIDC to authenticate with private registries, eliminating the need to store long-lived credentials as repository secrets. With OIDC-based authentication, {% data variables.product.prodname_dependabot %} update jobs can dynamically obtain short-lived credentials from your cloud identity provider.

{% data variables.product.prodname_dependabot %} supports OIDC authentication for any registry type that uses username and password authentication, when the registry is hosted on AWS CodeArtifact, Azure DevOps Artifacts, or JFrog Artifactory.

The benefits of OIDC authentication for {% data variables.product.prodname_dependabot %} are:

• Enhanced security: Eliminates static, long-lived credentials from your repositories.
• Simpler management: Enables secure, policy-compliant access to private registries.
• Avoid rate limiting: Dynamic credentials help you avoid hitting rate limits associated with static tokens.

For more information, see AUTOTITLE.

For more information about configuring OIDC, see AUTOTITLE.

For reference information about OIDC, see AUTOTITLE.