OpenID Connect リファレンス

OIDC トークンクレーム

          GitHubの OIDC プロバイダーでサポートされているすべての要求を表示するには、`claims_supported`https://token.actions.githubusercontent.com/.well-known/openid-configurationでエントリを確認します。

OIDC トークンには、次の要求が含まれています。

標準の audience、issuer、subject 要求

要求	要求の種類	説明
`aud`	対象ユーザー	既定では、これはリポジトリ所有者 (リポジトリを所有する Organization など) の URL です。ツールキットのコマンド (`core.getIDToken(audience)`) を使ってカスタムの対象ユーザーを設定できます
`iss`	発行者	OIDC トークンの発行者: `https://token.actions.githubusercontent.com`
`sub`	サブジェクト	クラウドプロバイダーによって検証されるサブジェクト要求を定義します。常に予測可能な方法でアクセストークンを割り当てるには、この設定が不可欠です。

追加の標準 JOSE ヘッダーパラメーターと要求

ヘッダーパラメーター	パラメーターのタイプ	説明
`alg`	アルゴリズム	OIDC プロバイダーによって使用されるアルゴリズム。
`kid`	キー識別子	OIDC トークンの一意のキー。
`typ`	タイプ	トークンの種類について説明します。これは JSON Web トークン (JWT) です。

要求	要求の種類	説明
`exp`	有効期限	JWT の有効期限を特定します。
`iat`	発行日時	JWT が発行された日時。
`jti`	JWT トークン識別子	OIDC トークンの一意識別子。
`nbf`	より前には可能ではありません	この時刻より前に JWT を使用することはできません。

          GitHub によって提供されるカスタム要求

要求	説明
`actor`	ワークフロー実行を開始した個人アカウント。
`actor_id`	ワークフロー実行を開始した個人アカウントの ID。
`base_ref`	ワークフロー実行における pull request のターゲットブランチ。
`check_run_id`	現在のジョブのチェック実行 ID。
`enterprise`	ワークフローが実行されているリポジトリを含む Enterprise の名前。
`enterprise_id`	ワークフローが実行されているリポジトリを含む Enterprise の ID。
`environment`	ジョブが使う環境の名前。

          `environment` 要求が含まれている場合 (`include_claim_keys` 経由でも)、環境が必要であり、指定する必要があります。                   |

          GHE.comでの置換値

プロバイダーの予想される要求は、 githubusercontent.com を SUBDOMAIN.ghe.com に置き換える必要があります。この場合、SUBDOMAIN は GHE.com上の企業のサブドメインです。
企業の名前またはスラッグを含むルートを含む URLは、 GHE.com上の企業のサブドメインに置き換える必要があります。

たとえば、サブドメインが octocorp、次のように置き換えます。

        GitHubの OIDC プロバイダーがサポートするすべてのクレームを見るためのURLは`https://token.actions.octocorp.ghe.com/.well-known/openid-configuration`です。

OIDC トークン内の iss の値は https://token.actions.octocorp.ghe.com になります。
エンタープライズは https://token.actions.octocorp.ghe.com/octocorp でトークンを受け取ることができ、issuer 値をカスタマイズするための REST API エンドポイントは /enterprises/octocorp/actions/oidc/customization/issuer になります。

クラウドロールでの信頼条件を定義するために使われる OIDC 要求

オーディエンスとサブジェクトのクレームは、通常、クラウドロール/リソースの条件を設定して、GitHubワークフローへのアクセスに範囲を設定する際に組み合わせて使用されます。 * Audience: 既定では、この値には組織またはリポジトリ所有者の URL を使います。これを使って、特定の組織内のワークフローのみがクラウドロールにアクセスできるように条件を設定できます。 * 件名： 既定では、定義済みの形式があり、 GitHub 組織、リポジトリ、ブランチ、関連付けられた job 環境など、ワークフローに関する一部の主要なメタデータを連結したものです。連結したメタデータからサブジェクト要求を組み立てる方法については、「サブジェクト要求の例」を参照してください。

より詳細な信頼条件が必要な場合は、JWT に含まれる issuer (iss) クレームと subject (sub) クレームをカスタマイズできます。詳細については、「トークンクレームのカスタマイズ」を参照してください。

また、OIDC トークンでサポートされている要求は他にも多数あり、これらの条件設定にも使用できます。さらに、クラウドプロバイダーがアクセストークンへのロール割り当てを許可していて、さらに細かいアクセス許可を指定できる場合があります。

メモ

クラウドプロバイダーがアクセストークンを発行する方法を制御するには、少なくとも 1 つの条件を定義し、信頼できないリポジトリがクラウドリソースにアクセストークンを要求できないようにする必要があります。

件名の主張の例

次の例は、"Subject" を条件として使う方法を示しています。また、連結したメタデータから "Subject" を組み立てる方法について説明します。 subject は job コンテキストの情報を使い、特定のブランチ、環境内で動作するワークフローからの要求に対してのみアクセストークン要求を許可するようにクラウドプロバイダーに指示します。以下のセクションでは、使用できる一般的な subject について説明します。

特定の環境用にフィルタリングを行う

ジョブから環境を参照するときに、subject 要求には環境名が含まれます。

特定の環境名にフィルター処理する subject を構成することができます。この例で、ワークフロー実行は、Production 組織が所有する octo-repo というリポジトリ内にある octo-org という環境を持つジョブから開始されている必要があります。

構文: repo:ORG-NAME/REPO-NAME:environment:ENVIRONMENT-NAME
例: repo:octo-org/octo-repo:environment:Production

          `pull_request` イベントを絞り込む

pull request イベントによってワークフローがトリガーされたとき、ジョブが環境を参照していない場合に限り、subject 要求には pull_request 文字列が含まれます。

          [
          `pull_request`
          ](/actions/using-workflows/events-that-trigger-workflows#pull_request) イベントにフィルター処理する subject を構成することができます。 この例で、ワークフロー実行は、`pull_request` 組織が所有する `octo-repo` というリポジトリ内の `octo-org` イベントによってトリガーされている必要があります。

構文: repo:ORG-NAME/REPO-NAME:pull_request
例: repo:octo-org/octo-repo:pull_request

特定のブランチにフィルター処理する

ジョブから環境を参照していない場合、かつ pull request イベントによってトリガーされたワークフローではない場合にのみ、subject 要求にはワークフローのブランチ名が含まれます。

特定のブランチ名にフィルター処理する subject を構成することができます。この例で、ワークフロー実行は、demo-branch 組織が所有する octo-repo というリポジトリ内にある octo-org というブランチから開始されている必要があります。

構文: repo:ORG-NAME/REPO-NAME:ref:refs/heads/BRANCH-NAME
例: repo:octo-org/octo-repo:ref:refs/heads/demo-branch

特定のタグをフィルター処理する

ジョブから環境を参照していない場合、かつ pull request イベントによってトリガーされたワークフローではない場合にのみ、subject 要求にはワークフローのタグ名が含まれます。

特定のタグに対してフィルターをかけるトピックを作成できます。この例で、ワークフロー実行は、demo-tag 組織が所有する octo-repo というリポジトリ内の octo-org というタグで開始されている必要があります。

構文: repo:ORG-NAME/REPO-NAME:ref:refs/tags/TAG-NAME
例: repo:octo-org/octo-repo:ref:refs/tags/demo-tag

メタデータを含む`:`のフィルタリング

メタデータ値内のすべての : は、サブジェクト要求の %3A に置き換えられます。

コロンを含むメタデータを含む件名を構成できます。この例で、ワークフロー実行は、Production:V1 組織が所有する octo-repo というリポジトリ内にある octo-org という環境を持つジョブから開始されている必要があります。

構文: repo:ORG-NAME/REPO-NAME:environment:ENVIRONMENT-NAME
例: repo:octo-org/octo-repo:environment:Production%3AV1

クラウドプロバイダーでの subject の構成

クラウドプロバイダーの信頼関係で subject を構成するには、その信頼の構成に subject 文字列を追加する必要があります。次の例は、さまざまなクラウドプロバイダーが同じ repo:octo-org/octo-repo:ref:refs/heads/demo-branch subject を異なる方法で受け入れる方法を示しています。

クラウドプロバイダー	例
アマゾンウェブサービス	`"token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:ref:refs/heads/demo-branch"`
Azure	`repo:octo-org/octo-repo:ref:refs/heads/demo-branch`
Google Cloud Platform	`(assertion.sub=='repo:octo-org/octo-repo:ref:refs/heads/demo-branch')`
HashiCorp Vault	`bound_subject="repo:octo-org/octo-repo:ref:refs/heads/demo-branch"`

特定のクラウドプロバイダーの構成について詳しくは、「デプロイメントのセキュリティ強化」に記載されているガイドをご覧ください。

トークンクレームのカスタマイズ

JWT に含まれる要求をカスタマイズすることで、OIDC 構成のセキュリティを強化できます。これらのカスタマイズを使用すると、ワークフローがクラウドでホストされているリソースにアクセスできるときに、クラウドロールに対してより詳しい信頼条件を定義できます。

          `issuer`または`audience`要求の値をカスタマイズできます。 「[企業の`issuer`値の](#customizing-the-issuer-value-for-an-enterprise)カスタマイズと`audience`[値のカスタマイズ](#customizing-the-audience-value)」を参照してください。

特定のリポジトリ、再利用可能なワークフロー、またはその他のソースからの JWT トークンを必要とする subject (sub) 要求に条件を設定することで、OIDC 構成の形式をカスタマイズできます。

        `repository_id` や `repository_visibility` などの追加の OIDC トークン要求を使用して、詳しい OIDC ポリシーを定義できます。 「[AUTOTITLE](/actions/concepts/security/openid-connect#understanding-the-oidc-token)」を参照してください。

リポジトリのカスタムプロパティを OIDC トークンに要求として含め、属性ベースのアクセス制御ポリシーを有効にすることができます。 OIDC トークンへのリポジトリのカスタムプロパティの組み込みを参照してください。

          `audience` 値のカスタマイズ

ワークフローでカスタムアクションを使用する場合、これらのアクションでは GitHub Actions Toolkit を使用して、 audience 要求のカスタム値を指定できます。また、一部のクラウドプロバイダーでは、公式のログインアクションでこれを使って、audience 要求の既定値が適用されます。たとえば、Azure Login の GitHub Action では、既定の値が提供されます。また、ワークフローでカスタム値を設定できます。 GitHub Actions ツールキットの詳細については、ドキュメントの OIDC トークンセクションを参照してください。

アクションによって提供される既定の aud 値を使用しない場合は、audience 要求のカスタム値を指定できます。これにより、特定のリポジトリまたは組織内のワークフローのみがクラウドロールにアクセスできるように条件を設定できます。使用するアクションでこれがサポートされている場合は、ワークフローで with キーワードを使って、カスタムの aud 値をアクションに渡すことができます。詳しくは、「メタデータ構文リファレンス」をご覧ください。

エンタープライズの `issuer` 値のカスタマイズ

既定では、JWT は GitHubの OIDC プロバイダー ( https://token.actions.githubusercontent.com) によって発行されます。このパスは、JWT の iss の値を使用してクラウドプロバイダーに提示されます。

OIDC 構成のセキュリティを強化するために、エンタープライズ管理者は、https://token.actions.githubusercontent.com/<enterpriseSlug> の一意の URL からトークンを受信するようにエンタープライズを構成できます。<enterpriseSlug> はエンタープライズのスラッグ値に置き換えます。

この構成は、Enterprise が一意の URL から OIDC トークンを受け取り、その URL からのトークンのみを受け入れるようにクラウドプロバイダーを構成できることを意味します。これにより、OIDC を使用してクラウドリソースにアクセスできるのが Enterprise のリポジトリだけになります。

エンタープライズでこの設定をアクティブにするには、エンタープライズ管理者が /enterprises/{enterprise}/actions/oidc/customization/issuer エンドポイントを使用し、要求本文で "include_enterprise_slug": true を指定する必要があります。詳しくは、「GITHUB ACTIONS OIDC の REST API エンドポイント」をご覧ください。

この設定を適用すると、JWT に更新された iss の値が含まれるようになります。次の例では、iss キーが octocat-inc をその enterpriseSlug 値として使用しています。

{
  "jti": "6f4762ed-0758-4ccb-808d-ee3af5d723a8",
  "sub": "repo:octocat-inc/private-server:ref:refs/heads/main",
  "aud": "http://octocat-inc.example/octocat-inc",
  "enterprise": "octocat-inc",
  "enterprise_id": "123",
  "iss": "https://token.actions.githubusercontent.com/octocat-inc",
  "bf": 1755350653,
  "exp": 1755351553,
  "iat": 1755351253
}

OIDC トークンにリポジトリカスタムプロパティを含める

メモ

この機能は現在パブリックプレビュー段階であり、変更される可能性があります。

組織およびエンタープライズ管理者は、アクション OIDC トークンに要求として含めるリポジトリのカスタムプロパティを選択できます。カスタムプロパティが OIDC 構成に追加されると、そのプロパティの値が設定されている組織内または企業のすべてのリポジトリが、その OIDC トークンに自動的に含められます。プロパティ名は、プレフィックスとして repo_property_ が付いたトークンに表示されます。

これにより、リポジトリメタデータに直接バインドする属性ベースのアクセス制御 (ABAC) ポリシーをクラウドプロバイダーに作成できるため、構成の誤差が軽減され、リポジトリごとに個別のアクセス構成を管理する必要がなくなります。

カスタムプロパティを含める場合の前提条件

カスタムプロパティは、組織レベルまたはエンタープライズレベルで既に定義されている必要があります。
組織管理者またはエンタープライズ管理者である必要があります。
OIDC 構成にカスタムプロパティを追加すると、そのプロパティの値が設定されている組織内または企業のすべてのリポジトリが、OIDC トークンに自動的に含められます。

OIDC トークン要求へのカスタムプロパティの追加

設定 UI または REST API を使用して、OIDC トークンに含めるカスタムプロパティを管理できます。

```
        **設定 UI の使用:** 
```
組織または企業の Actions OIDC 設定に移動して、OIDC トークンに含まれるカスタムプロパティを表示および構成します。
```
        **REST API を使用する場合:**
```
組織または企業の OIDC トークン要求にカスタムプロパティを追加するには、REST API を使用します。詳しくは、「GITHUB ACTIONS OIDC の REST API エンドポイント」をご覧ください。

カスタムプロパティを持つトークンの例

カスタムプロパティが OIDC 構成に追加されると、そのプロパティの値が設定されているリポジトリはトークンに含まれます。次の例では、 workspace_id カスタムプロパティがトークンに repo_property_workspace_id として表示されます。

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

これらの repo_property_* 要求は、クラウドプロバイダーの信頼ポリシーの条件として使用できます。例については、「例: リポジトリのカスタムプロパティに対するフィルター処理」を参照してください。

組織またはリポジトリの subject 要求のカスタマイズ

セキュリティ、コンプライアンス、標準化を向上させるため、必要なアクセス条件に合わせて標準要求をカスタマイズできます。クラウドプロバイダーが subject 要求に関する条件をサポートしている場合は、sub の値が "job_workflow_ref:octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main" などの再利用可能なワークフローのパスと一致するかどうかをチェックする条件を作成できます。正確な形式は、クラウドプロバイダーの OIDC 構成によって異なります。 GitHubで一致条件を構成するには、REST API を使用して、sub要求に常に特定のカスタム要求 (job_workflow_ref など) を含める必要があることを要求できます。 subREST API を使って、OIDC subject 要求のカスタマイズテンプレートを適用できます。たとえば、OIDC トークン内の要求に、job_workflow_refなどの特定のカスタム要求を常に含めるように要求できます。詳しくは、「GITHUB ACTIONS OIDC の REST API エンドポイント」をご覧ください。

メモ

organization テンプレートが適用されている場合、リポジトリがカスタム organization テンプレートにオプトインしていない限り、OIDC を既に使用しているワークフローには影響しません。既存および新規のすべてのリポジトリについて、リポジトリ所有者はリポジトリレベルの REST API を使用して、use_default を false に設定することで、この構成を受け取ることをオプトインする必要があります。または、リポジトリ所有者は REST API を使って、リポジトリに固有の別の構成を適用することもできます。詳しくは、「GITHUB ACTIONS OIDC の REST API エンドポイント」をご覧ください。

          `sub` 要求のカスタマイズによって、`sub`で説明されているトークンにおける既定の事前定義された[](#example-subject-claims)形式が新しい形式に置き換えられます。

メモ

          `sub` 要求では、リポジトリを参照する `repo` の代わりに短縮形式 `repo:ORG-NAME/REPO-NAME` (たとえば `repository`) が使用されます。

コンテキスト値内の : は、 %3Aに置き換えられます。

次のテンプレート例は、subject 要求をカスタマイズするさまざまな方法を示しています。 GitHubでこれらの設定を構成するには、管理者は REST API を使用して、サブジェクト (sub) 要求に含める必要がある要求の一覧を指定します。

この構成を適用するには、API エンドポイントに要求を送信し、要求本文に必要な構成を含めます。 Organization については「GITHUB ACTIONS OIDC の REST API エンドポイント」を、リポジトリについては「GITHUB ACTIONS OIDC の REST API エンドポイント」を参照してください。

subject クレームをカスタマイズするには、クラウドプロバイダーの OIDC 構成で最初に一致条件を作成し、その後 REST API を使用して構成をカスタマイズする必要があります。構成が完了すると、新しいジョブが実行されるたびに、そのジョブの間に生成された OIDC トークンが新しいカスタマイズテンプレートに従うようになります。ジョブの実行前にクラウドプロバイダーの OIDC 構成に一致条件が存在しない場合、クラウド条件が同期されない可能性があるため、生成されたトークンがクラウドプロバイダーによって受け入れられない可能性があります。

例: 可視性と所有者に基づいたリポジトリの許可

このテンプレート例では、sub 要求に repository_owner と repository_visibility を使用する新しい形式を指定できます。

{
   "include_claim_keys": [
       "repository_owner",
       "repository_visibility"
   ]
}

クラウドプロバイダーの OIDC 構成で、条件に sub と repository_owner の特定の値を含める必要があることを要求する repository_visibility 条件を構成します。たとえば、 "sub": "repository_owner:monalisa:repository_visibility:private"と指定します。この方法では、クラウドロールのアクセスを、Organization または Enterprise 内のプライベートリポジトリのみに制限できます。

例: 特定の所有者が設定されているすべてのリポジトリへのアクセスの許可

このテンプレート例では、sub 要求に repository_owner の値のみを含む新しい形式を指定できます。

{
   "include_claim_keys": [
       "repository_owner"
   ]
}

クラウドプロバイダーの OIDC 構成で、条件に sub の特定の値を含める必要があることを要求する repository_owner 条件を構成します。例: "sub": "repository_owner:monalisa"

例: 再利用可能なワークフローの要求

このテンプレート例では、sub クレームの値を含む新しい形式を job_workflow_ref クレームに設定できます。これにより、Enterprise は再利用可能なワークフローを使用して、Organization とリポジトリ全体に一貫した展開を適用できます。

  {
     "include_claim_keys": [
         "job_workflow_ref"
     ]
  }

クラウドプロバイダーの OIDC 構成で、条件に sub の特定の値を含める必要があることを要求する job_workflow_ref 条件を構成します。たとえば、 "sub": "job_workflow_ref:octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main"と指定します。

例: 再利用可能なワークフローとその他の要求の要件化

次のテンプレート例では、特定の再利用可能なワークフローの要件と追加の要求を組み合わせています。

この例では、"context" を使用して条件を定義する方法も示しています。これは、既定の sub の形式でリポジトリに続く部分です。たとえば、ジョブが環境を参照する場合、コンテキストには environment:ENVIRONMENT-NAME が含まれています。

{
   "include_claim_keys": [
       "repo",
       "context",
       "job_workflow_ref"
   ]
}

クラウドプロバイダーの OIDC 構成で、条件に sub、repo、context の特定の値を含める必要があることを要求する job_workflow_ref 条件を構成します。

このカスタマイズテンプレートでは、sub が repo:ORG-NAME/REPO-NAME:environment:ENVIRONMENT-NAME:job_workflow_ref:REUSABLE-WORKFLOW-PATH の形式を使用する必要があります。例: "sub": "repo:octo-org/octo-repo:environment:prod:job_workflow_ref:octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main"

例: 特定のリポジトリへのアクセスの許可

このテンプレート例では、すべてのブランチやタグ、そして環境にわたって、クラウドが特定のリポジトリ内のすべてのワークフローにアクセスできるようになります。セキュリティをさらに向上させるには、「企業の issuer 値のカスタマイズ」の説明に従って、このテンプレートを企業の一意の発行者 URL と組み合わせることができます。

{
   "include_claim_keys": [
       "repo"
   ]
}

クラウドプロバイダーの OIDC 構成で、必要な値と一致する sub 要求を必要とするように repo 条件を構成します。

例: システム生成 GUID の使用

このテンプレート例では、エンティティの名前変更 (リポジトリの名前変更など) 間で変更されないシステム生成 GUID を使用する予測可能な OIDC 要求が有効になります。

  {
     "include_claim_keys": [
         "repository_id"
     ]
  }

クラウドプロバイダーの OIDC 構成で、必要な値と一致する sub 要求を必要とするように repository_id 条件を構成します。

または

{
   "include_claim_keys": [
       "repository_owner_id"
   ]
}

クラウドプロバイダーの OIDC 構成で、必要な値と一致する sub 要求を必要とするように repository_owner_id 条件を構成します。

例: `:` を含むコンテキスト値

この例では、: を使ってコンテキスト値を処理する方法を示します。たとえば、ジョブが production:eastus という名前の環境を参照する場合です。

{
   "include_claim_keys": [
       "environment",
       "repository_owner"
   ]
}

クラウドプロバイダーの OIDC 構成で、クレームの sub と environment に特定の値が含まれることを要求する repository_owner 条件を構成します。たとえば、 "sub": "environment:production%3Aeastus:repository_owner:octo-org"と指定します。

例: リポジトリのカスタムプロパティに対するフィルター処理

このテンプレート例では、 sub 要求にリポジトリのカスタムプロパティ要求を含めることができます。 OIDC トークンに含まれるカスタムプロパティは、トークンに repo_property_ が付いたプレフィックスで表示されますが、 include_claim_keys 値では、トークンに表示される完全な要求名が使用されます。

{
   "include_claim_keys": [
       "repo_property_workspace_id"
   ]
}

クラウドプロバイダーの OIDC 構成で、条件に sub の特定の値を含める必要があることを要求する repo_property_workspace_id 条件を構成します。たとえば、 "sub": "repo_property_workspace_id:ws-abc123"と指定します。

組織テンプレートのカスタマイズのリセット

このテンプレート例では、subject 要求を既定の形式にリセットしています。このテンプレートは、組織レベルのカスタマイズポリシーから実質的にオプトアウトします。

{
   "include_claim_keys": [
       "repo",
       "context"
   ]
}

クラウドプロバイダーの OIDC 構成で、条件に sub と repo の特定の値を含める必要があることを要求する context 条件を構成します。

リポジトリテンプレートのカスタマイズのリセット

組織内のすべてのリポジトリには、(組織とリポジトリレベルの) カスタマイズされた sub 要求テンプレートをオプトインまたはオプトアウトする機能があります。

リポジトリをオプトアウトし、既定の sub 要求形式にリセットするには、リポジトリ管理者が「GITHUB ACTIONS OIDC の REST API エンドポイント」の REST API エンドポイントを使用する必要があります。

既定の sub 要求形式を使うようにリポジトリを構成するには、PUT /repos/{owner}/{repo}/actions/oidc/customization/subREST API エンドポイントを使い、次の要求本文を指定する必要があります。

{
   "use_default": true
}

例: 組織のテンプレートを使うようにリポジトリを構成する

組織がテンプレートを作成したら、REST API を使って、組織内のリポジトリにカスタマイズされた sub 要求テンプレートをプログラムで適用することができます。リポジトリ管理者は、自分の組織の管理者によって作成されたテンプレートを使うようにリポジトリを構成できます。

Organization のテンプレートを使うようにリポジトリを構成するには、リポジトリ管理者が PUT /repos/{owner}/{repo}/actions/oidc/customization/subREST API エンドポイントを使い、次の要求本文を指定する必要があります。詳しくは、「GITHUB ACTIONS OIDC の REST API エンドポイント」をご覧ください。

{
   "use_default": false
}

OIDC 要求のデバッグ

          [
          `github/actions-oidc-debugger`
          ](https://github.com/github/actions-oidc-debugger) アクションを使用すると、クラウド プロバイダーと統合する前に、送信される要求を視覚化できます。 このアクションは JWT を要求し、 GitHub Actionsから受信した JWT に含まれる要求を出力します。

OIDC トークンを要求するためのワークフローのアクセス許可

必要な権限

ジョブまたはワークフローは、id-token: writeアクセス許可を付与してGitHubの OIDC プロバイダーが JSON Web トークン (JWT) を作成できるようにする必要があります。
```
permissions:
  id-token: write
```

        `id-token: write` がないと、OIDC JWT ID トークンを要求できません。 この設定では、OIDC トークンのフェッチと設定のみが有効になります。他のリソースへの書き込みアクセスは許可されません。

アクセス許可の設定

ワークフローの OIDC トークンをフェッチするには、ワークフローレベルでアクセス許可を設定します。

permissions:
  id-token: write # This is required for requesting the JWT
  contents: read # This is required for actions/checkout

1 つのジョブの OIDC トークンをフェッチするには、そのジョブ内でアクセス許可を設定します。
```
permissions:
  id-token: write # This is required for requesting the JWT
```
ワークフローのニーズによっては、追加のアクセス許可が必要になる場合があります。

再利用可能なワークフロー

呼び出し元と同じユーザー、organization、または Enterprise が所有する再利用可能なワークフローの場合は、再利用可能なワークフローで生成された OIDC トークンに呼び出し元のコンテキストからアクセスできます。
Enterprise または organization の外部の再利用可能なワークフローの場合は、permissions の id-token 設定を、呼び出し元のワークフローまたはジョブのレベルで明示的に write に設定します。これにより、OIDC トークンは目的の呼び出し元ワークフローでのみ使用できるようになります。

OIDC トークンを要求するための方法

カスタムアクションでは、次を使用して OIDC トークンを要求できます。

アクションツールキットの getIDToken() メソッド。詳しくは、npm パッケージのドキュメントの「OIDC トークン」をご覧ください。

ランナーで設定される以下の環境変数。

変数	説明
`ACTIONS_ID_TOKEN_REQUEST_URL`

        GitHubの OIDC プロバイダーの URL。 |

| ACTIONS_ID_TOKEN_REQUEST_TOKEN | OIDC プロバイダーに対する要求のベアラートークン。 |

次に例を示します。

Shell

curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=api://AzureADTokenExchange"

curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=api://AzureADTokenExchange"

この記事で