Configuring OpenID Connect in Docker

Use OpenID Connect within your workflows to authenticate with Docker without storing long-lived credentials.

Overview

OpenID Connect (OIDC) allows your GitHub Actions workflows to authenticate with Docker to access Docker Hub and Docker Build Cloud without storing Docker passwords, personal access tokens, or organization access tokens (OATs) in GitHub.

Instead of managing long-lived credentials, you configure a trust relationship between your GitHub organization and your Docker organization. When a workflow runs, GitHub issues a short-lived OIDC token that Docker validates against your configured rulesets, then issues a scoped access token for the workflow.

This guide gives an overview of how to configure Docker to trust GitHub's OIDC as a federated identity, and demonstrates how to use this configuration in a GitHub Actions workflow.

For more information, see OIDC connections in the Docker documentation.

Prerequisites

Adding the identity provider to Docker

To use OIDC with Docker, establish a trust relationship between GitHub Actions and Docker by creating an OIDC connection. For more information about this process, see Create and manage OIDC connections in the Docker documentation.

  1. Sign in to Docker Home and navigate to your organization.
  2. Go to Identity & auth > OIDC connections.
  3. Select Create OIDC connection.
  4. Configure at least one ruleset to define which GitHub repositories, branches, or workflows can authenticate. Each ruleset specifies:
  5. Save the connection and copy the connection ID for use in your workflow.

Updating your GitHub Actions workflow

Once you have created an OIDC connection in Docker, update your workflow to authenticate using the docker/login-action action.

The following example uses the placeholder YOUR-CONNECTION-ID for the connection ID you copied from Docker, and YOUR-DOCKER-ORG for your Docker organization name.

# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.
permissions:
  id-token: write
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v6

      - name: Sign in to Docker Hub with OIDC
        uses: docker/login-action@abd2ef45e78c5afb21d64d4ca52ee8550d9572c7 # v4.5.1
        with:
          username: YOUR-DOCKER-ORG
        env:
          DOCKERHUB_OIDC_CONNECTIONID: YOUR-CONNECTION-ID

      - name: Build and push
        uses: docker/build-push-action@10e90e3645eae34f1e60eeb005ba3a3d33f178e8 # v6
        with:
          push: true
          tags: YOUR-DOCKER-ORG/my-image:latest

Key workflow settings

Subject claim matching

Docker evaluates the sub claim from the GitHub OIDC token against the rulesets you configured. The default subject claim format is:

repo:<owner>/<repo>:ref:refs/heads/<branch>

Note

Repositories created after July 15, 2026, and repository renames or transfers after that date, use an immutable default OIDC sub claim that includes owner and repository IDs. Existing repositories keep the previous format unless they opt in. For more information, see OpenID Connect reference.

Different workflow triggers produce different subject claims. For example:

Trigger Subject claim format
Branch push repo:my-org/my-repo:ref:refs/heads/main
Pull request repo:my-org/my-repo:pull_request
Tag repo:my-org/my-repo:ref:refs/tags/v1.0
Environment repo:my-org/my-repo:environment:production

You can use wildcard patterns in your rulesets to match multiple repositories or branches. For legacy subject claims, repo:my-org/* matches all repositories in the organization. For immutable subject claims, use repo:my-org@OWNER-ID/*; if the organization contains repositories using both formats, configure both patterns.

For more information, see Rulesets and subject claims in the Docker documentation.