OpenID Connect を使ったセキュリティ強化について

OpenID Connect の概要

多くの場合、GitHub Actions ワークフローは、ソフトウェアをデプロイするため、またはクラウドのサービスを使うために、クラウド プロバイダー (AWS、Azure、GCP、HashiCorp Vault など) にアクセスするように設計されています。 ワークフローは、このようなリソースにアクセスできるように、パスワードやトークンなどの資格情報をクラウド プロバイダーに事前に提供します。 通常、このような資格情報は GitHub にシークレットとして格納されており、ワークフローは、実行時に毎回このシークレットをクラウド プロバイダーに提示します。

ただし、ハードコーディングされたシークレットを使うには、クラウド プロバイダーで資格情報を作成し、それをシークレットとして GitHub に複製する必要があります。

OpenID Connect (OIDC) を使って、有効期間が短いアクセス トークンをクラウド プロバイダーに直接要求するようにワークフローを構成するという別の方法を採ることもできます。 クラウド プロバイダー側でも OIDC をサポートする必要がある場合は、アクセス トークンを要求できるワークフローを制御する信頼関係を構成する必要があります。 現在 OIDC をサポートしているプロバイダーとして、アマゾン ウェブ サービス、Azure、Google Cloud Platform、HashiCorp Vault などがあります。

OIDC を使う利点

OIDC トークンを使うようにワークフローを更新することで、次のような優れたセキュリティ プラクティスを採用できます。

• クラウド シークレットなし: 有効期間が長い GitHub シークレットとしてクラウドの資格情報を複製する必要はありません。 代わりに、クラウド プロバイダー上で OIDC 信頼を構成し、OIDC を介して有効期間が短いアクセス トークンをクラウド プロバイダーに要求するようにワークフローを更新することができます。
• 認証と認可の管理: クラウド プロバイダーの認証 (authN) および認可 (authZ) ツールを使ってクラウド リソースへのアクセスを制御することで、ワークフローから資格情報を使用する方法をより細かく制御できます。
• 資格情報のローテーション: OIDC を使う場合、1 つのジョブに対してのみ有効であり、自動的に失効する有効期間が短いアクセス トークンがクラウド プロバイダーから発行されます。

OIDC の概要

次の図は、GitHub の OIDC プロバイダーがワークフローやクラウド プロバイダーとどのように統合されているかを示す概要です。

1. クラウド プロバイダー内に、クラウド ロールと、クラウドへのアクセスを必要とする GitHub ワークフローとの間に OIDC 信頼を作成します。
2. ジョブを実行するたびに、GitHub の OIDC プロバイダーによって OIDC トークンが自動生成されます。 このトークンには、認証対象の特定のワークフローに関する、セキュリティが強化された検証可能な ID を確立するための複数の要求が含まれています。
3. このトークンを GitHub の OIDC プロバイダーに要求し、クラウド プロバイダーに提示するステップまたはアクションをジョブ内に含めることができます。
4. クラウド プロバイダーは、トークンで提示した要求の検証を完了した後に、ジョブの期間中にのみ使用できる有効期間の短いクラウド アクセス トークンを提供します。

クラウドを使った OIDC 信頼の構成

GitHub の OIDC プロバイダーを信頼するようにクラウドを構成する場合は、受信する要求をフィルター処理する条件を追加する必要があります。これは、信頼できないリポジトリやワークフローがクラウド リソースに対してアクセス トークンを要求できないようにするためです。

• クラウド プロバイダーは、アクセス トークンを付与する前に、信頼設定で条件を設定するために使われた subject と他の要求が、要求の JSON Web トークン (JWT) 内のものと一致するかどうかを確認します。 そのため、クラウド プロバイダーで subject や他の条件を正しく定義するように注意する必要があります。
• OIDC 信頼の構成手順と、(Subject やその他の要求を使って) クラウド ロールの条件を設定する構文は、利用しているクラウド プロバイダーによって異なります。 例については、「サブジェクト要求の例」を参照してください。

OIDC トークンの概要

各ジョブは GitHub の OIDC プロバイダーに OIDC トークンを要求し、その応答として、自動的に生成された JSON Web トークン (JWT) が返されます。これは生成されたワークフロー ジョブごとに一意です。 このジョブを実行すると、OIDC トークンがクラウド プロバイダーに提示されます。 クラウド プロバイダーは、トークンを検証するために、OIDC トークンの subject とその他の要求がクラウド ロールの OIDC 信頼定義に事前に構成されている条件と一致するかどうかを確認します。

次の OIDC トークン例では、octo-org/octo-repo リポジトリ内の prod というジョブ環境を参照する subject (sub) を使っています。

{
  "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": "https://github.com/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",
  "enterprise": "avocado-corp"
  "ref_type": "branch",
  "job_workflow_ref": "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main",
  "iss": "https://token.actions.githubusercontent.com",
  "nbf": 1632492967,
  "exp": 1632493867,
  "iat": 1632493567
}

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

このトークンには、標準の対象ユーザー、発行者、サブジェクト要求が含まれています。

OIDC トークンには追加の標準要求も含まれています。

トークンには、GitHub によって提供されるカスタム要求も含まれています。

OIDC 要求を使ったクラウド ロールに対する信頼条件の定義

OIDC を使う場合、クラウド プロバイダー内のリソースにアクセスするには、GitHub Actions ワークフローにトークンが必要です。 ワークフローはクラウド プロバイダーにアクセス トークンを要求します。そこで、JWT から提示された詳細が確認されます。 JWT の信頼構成が一致した場合、クラウド プロバイダーは、応答として一時的なトークンをワークフローに発行します。これを使って、クラウド プロバイダー内のリソースにアクセスできるようになります。 特定の組織のリポジトリから送信された要求のみに応答するようにクラウド プロバイダーを構成することができます。また、後述する追加の条件を指定することもできます。

通常、Audience と Subject の要求は、GitHub ワークフローへのアクセスにスコープを設定する目的で、クラウド ロールやリソースに対する条件の設定時に組み合わせて使います。

• Audience: 既定では、この値には組織またはリポジトリ所有者の URL を使います。 これを使って、特定の組織内のワークフローのみがクラウド ロールにアクセスできるように条件を設定できます。
• Subject: 既定では、事前に定義された書式があります。GitHub の Organization、リポジトリ、ブランチ、関連付けられた job 環境など、ワークフローに関する主要なメタデータの一部を連結したものです。 連結したメタデータからサブジェクト要求を組み立てる方法については、「サブジェクト要求の例」を参照してください。

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

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

subject 要求の例

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

特定の環境にフィルター処理する

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

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

• 構文: repo:<orgName/repoName>:environment:<environmentName>
• 例:repo:octo-org/octo-repo:environment:Production

pull_request イベントにフィルター処理する

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

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

• 構文: repo:<orgName/repoName>:pull_request
• 例: repo:octo-org/octo-repo:pull_request

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

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

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

• 構文: repo:<orgName/repoName>:ref:refs/heads/branchName
• 例: repo:octo-org/octo-repo:ref:refs/heads/demo-branch`

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

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

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

• 構文: repo:<orgName/repoName>:ref:refs/tags/<tagName>
• 例: repo:octo-org/octo-repo:ref:refs/tags/demo-tag

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

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

詳細については、「クラウド プロバイダーの OpenID Connect を有効にする」を参照してください。

OIDC 向けのアクションの更新

OIDC を使って認証するためにカスタム アクションを更新するには、Actions ツールキットの getIDToken() を使って、GitHub の OIDC プロバイダーに JWT を要求することができます。 詳細については、npm パッケージ ドキュメントの「OIDC トークン」を参照してください。

また、curl コマンドを使用し、次の環境変数を使って JWT を要求することもできます。

次に例を示します。

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

アクセス許可設定の追加

ジョブまたはワークフローの実行には、id-token: write の permissions 設定が必要です。 id-token の permissions 設定が read または none の場合、OIDC JWT ID トークンを要求することはできません。

この id-token: write 設定により、次のいずれかの方法を使用して、GitHub の OIDC プロバイダーから JWT を要求できます。

• ランナーで環境変数を使用する (ACTIONS_ID_TOKEN_REQUEST_URL および ACTIONS_ID_TOKEN_REQUEST_TOKEN)。
• アクション ツールキットから getIDToken() を使用する。

ワークフローの 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

ワークフローの要件に応じて、ここで追加のアクセス許可を指定する必要がある場合があります。

再利用可能なワークフローについては、id-token の permissions 設定を、呼び出し元ワークフロー レベルか、再利用可能ワークフローを呼び出す特定のジョブで write に設定してください。 詳しくは、「ワークフローの再利用」を参照してください。

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

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

• セキュリティのレイヤーを追加するために、issuer URL に Enterprise スラッグを追加できます。 これにより、issuer (iss) の要求に条件を設定し、Enterprise スラッグを含める必要がある一意の issuer URL からの JWT トークンのみを受け入れるように構成できます。
• 特定のリポジトリ、再利用可能なワークフロー、またはその他のソースからの JWT トークンを必要とする subject (sub) 要求に条件を設定することで、OIDC 構成を標準化できます。
• repository_id や repository_visibility などの追加の OIDC トークン要求を使用して、詳しい OIDC ポリシーを定義できます。 詳細については、「OpenID Connect を使ったセキュリティ強化について」を参照してください。

これらの要求形式をカスタマイズするには、Organization とリポジトリの管理者が、次のセクションで説明する REST API エンドポイントを使用できます。

一意のトークン URL への切り替え

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

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

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

Enterprise でこの設定をアクティブにするには、Enterprise 管理者が /enterprises/{enterprise}/actions/oidc/customization/issuer エンドポイントを使用し、要求本文で "include_enterprise_slug": true を指定する必要があります。 詳しくは、「GitHub Actions OIDC」を参照してください。

この設定を適用すると、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"
  "iss": "https://token.actions.githubusercontent.com/octocat-inc",
  "bf": 1755350653,
  "exp": 1755351553,
  "iat": 1755351253
}

組織またはリポジトリの 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 などの特定のカスタム要求を含める必要があることを求めることができます。 OIDC REST API を使って、OIDC subject 要求のカスタマイズ テンプレートを適用できます。たとえば、OIDC トークン内の sub 要求に、job_workflow_ref などの特定のカスタム要求を常に含めるように要求できます。

sub 要求全体に対して要求の結果を新しい形式でカスタマイズすると、「OpenID Connect を使ったセキュリティ強化について」で説明されているトークンの事前に定義された既定の sub 形式が置き換えられます。

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

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

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

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

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

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

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

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

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

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

{
   "include_claim_keys": [
       "repository_owner"
   ]
}

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

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

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

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

  {
     "include_claim_keys": [
         "job_workflow_ref"
     ]
  }

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

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

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

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

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

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

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

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

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

このテンプレート例では、すべてのブランチやタグ、そして環境にわたって、クラウドが特定のリポジトリ内のすべてのワークフローにアクセスできるようになります。 セキュリティをさらに強化するには、「一意のトークン URL への切り替え」で説明されているとおり、このテンプレートを Enterprise の issuer URL に組み合わせるのがよいでしょう。

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

{
   "include_claim_keys": [
       "repo"
   ]
}

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

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

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

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

  {
     "include_claim_keys": [
         "repository_id"
     ]
  }

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

または

{
   "include_claim_keys": [
       "repository_owner_id"
   ]
}

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

カスタマイズのリセット

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

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

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

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

既定の subject 要求の使用

Organization から subject 要求ポリシーを受け取ることができるリポジトリの場合、リポジトリ所有者は後でオプトアウトを選び、代わりに既定の sub 要求形式を使用できます。 これは、そのリポジトリで組織のカスタマイズされたテンプレートが使用されないことを意味します。

既定の sub 要求形式を使うようにリポジトリを構成するには、リポジトリ管理者が「GitHub Actions OIDC」の REST API エンドポイントを使い、次の要求本文を指定する必要があります。

{
   "use_default": true
}

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

リポジトリ管理者は、自分の組織の管理者によって作成されたテンプレートを使うようにリポジトリを構成できます。

Organization のテンプレートを使うようにリポジトリを構成するには、リポジトリ管理者が「GitHub Actions OIDC」の REST API エンドポイントを使い、次の要求本文を指定する必要があります。

{
   "use_default": false
}

OIDC 向けのワークフローの更新

シークレットではなく OIDC アクセス トークンを使うように YAML ワークフローを更新できるようになりました。 一般的なクラウド プロバイダーは公式のログイン アクションを公開しているので、OIDC を簡単に使い始めることができます。 ワークフローの更新の詳細については、「クラウド プロバイダーの OpenID Connect を有効にする」の後半に掲載されているクラウド固有のガイドを参照してください。

クラウド プロバイダーの OpenID Connect を有効にする

特定のクラウド プロバイダーに対して OIDC を有効にして構成する方法については、次のガイドを参照してください。

• 「アマゾン ウェブ サービスでの OpenID Connect の構成」
• 「Azure での OpenID Connect の構成」
• Google Cloud Platform での OpenID Connect の構成
• 「HashiCorp Vault での OpenID Connect の構成」

別のクラウド プロバイダーに対して OIDC を有効にして構成する方法については、次のガイドを参照してください。

• 「クラウド プロバイダーでの OpenID Connect の構成」