OIDC プロバイダー（OpenID Connect プロバイダー）

2026年4月4日

OIDC プロバイダーとは

OIDC プロバイダーは、一言でいうとこの人は誰かを証明してくれる認証サーバーです。OIDC は OpenID Connect の略で、OAuth 2.0 の上に載った「認証」のための仕組みです。OAuth 2.0 自体は本来「アクセス権限の委譲」の仕組みですが、OIDC を使うと、その上でログインしたユーザー本人の確認までできるようになります。

例えば、Webアプリで「Googleでログイン」や「Microsoftでログイン」を押したとき、Google や Microsoft が OIDC プロバイダーとして動くことがあります。アプリ側は、そのプロバイダーから受け取った情報を検証して、「このユーザーは確かに認証済みだ」と判断します。

OIDC と OAuth 2.0 の違い

一番大きな違いは、以下です。

OAuth 2.0 は認可の仕組み
OIDC は認証を追加した仕組み

OAuth 2.0 は、このアプリにどのデータへのアクセス権を渡すかを扱います。つまり権限を渡す仕組みです。OIDC は、OAuth 2.0 の上に乗って、このユーザーは誰かまで分かるようにした仕組みです。

具体的な OIDC プロバイダーサービス

実際に使うのは、OIDC や OAuth 2.0 に対応した以下の認証サービスや製品です。

Google
Microsoft Entra ID
Okta
Auth0
Amazon Cognito
Keycloak

ちなみに上記の多くは SSO に対応しています。

HCP Terraform の OIDC について

具体的に OIDC の流れを説明していきます。HCP Terraform の OIDC は HCP Terraform の run（plan/apply）が、自分が正当な Terraform 実行であることを外部システムに証明する仕組みです。人間がブラウザでログインするための OIDC というより、Terraform ワークロード用の OIDC です。HashiCorp ではこれを Workload Identity として説明しています。HCP Terraform の場合の OIDC プロバイダーは Terraform になります。

※下にある Workload Identity Token の具体例にもあるように、iss（issuer、OIDC プロバイダー）は https://app.terraform.io で設定されています。

もともとは HCP Terraform の Workspace に AWS アクセスキー/シークレットアクセスキーを入れていましたが、Run ごとに短命な認証情報を発行して使うための仕組みです。HCP Terraform が直接 AWS のアクセスキーを永続保持するのではなく、OIDC トークンを使って毎回その場で一時資格情報を受け取ります。

認証の流れ

ざっくりと以下のような流れになります。

HCP Terraform はクラウドの秘密鍵を持たない
代わりに、自分が誰かを示す OIDC トークンを毎回出す
クラウド側がそのトークンを検証して、一時クレデンシャルを返す

認証認可の全体の流れ

HCP Terraform の Dynamic Credentials の流れは、以下の流れになります。

HCP Terraform が OIDC 準拠の Workload Identity Token を生成する。
Plan/Apply 開始時に、そのトークンをクラウド側（AWS など）へ渡す。
クラウド側（AWS など）が HCP Terraform の公開鍵でトークンを検証する。
検証が通れば、クラウド側（AWS の STS など）が短命の一時クレデンシャルを返す。
HCP Terraform はその Run 環境内で Provider にその資格情報を渡す。
Run 完了後、実行環境は破棄され、一時クレデンシャルも捨てられる。

以下のようなイメージです。

HCP Terraform
  └─ Workload Identity Token(JWT) を発行

        ↓

AWS STS: AssumeRoleWithWebIdentity
  └─ token を検証
  └─ IAM role の trust policy を評価

        ↓

一時クレデンシャルを返す
  ├─ AccessKeyId
  ├─ SecretAccessKey
  └─ SessionToken

        ↓

Terraform AWS provider がその資格情報で AWS API を実行

Workload Identity Token の具体例

実際に通信する際は Base64URL エンコードされています。暗号化されているわけではないので秘匿性はありません。目的は改ざん防止です。

{
  "header": {
    "typ": "JWT",
    "alg": "RS256",
    "kid": "dummy-key-1"
  },
  "payload": {
    "iss": "https://app.terraform.io",
    "aud": "aws.workload.identity",
    "sub": "organization:my-org:project:Default Project:workspace:prod-infra:run_phase:apply",
    "terraform_organization_name": "my-org",
    "terraform_project_name": "Default Project",
    "terraform_workspace_name": "prod-infra",
    "terraform_run_phase": "apply",
    "iat": 1712300000,
    "nbf": 1712300000,
    "exp": 1712303600
  },
  "signature": "ZHVtbXktc2lnbmF0dXJlLWZvcxxxxxxxxxxxxxx"
}

短命な一時クレデンシャルの具体例

以下のような感じでアクセスキーとシークレットアクセスキーとトークンと期限が入っています。

{
  "AccessKeyId": "ASIAQEXAMPLE123456789",
  "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
  "SessionToken": "IQoJb3JpZ2luX2VjEJf//////////wEaCrtration1234567890abcdefghijklmnopqrstuvwxyz",
  "Expiration": "2026-04-04T12:30:00Z"
}

STS がどのように関係しているか

STS は OIDCトークンを受け取って、AWS用の一時クレデンシャルに交換する窓口として関わってきます。HCP Terraform が出す Workload Identity Token を、AWS がそのままアクセスキーとして使うわけではありません。AWS では STS の AssumeRoleWithWebIdentity を使って、そのトークンを検証し、成功したら 一時的なセキュリティクレデンシャルを返します。

HCP Terraform が OIDC token を発行 → その token を STS に渡す → STS が issuer・署名・aud・sub などを確認 → 条件に合えば IAMロールを引き受けさせる → STS が AccessKeyId / SecretAccessKey / SessionToken を返す、という順番です。

Terraform における Workload Identity Token とは

Terraformにおける Workload Identity Token とは、主に HCP Terraform や Terraform Enterprise が各実行（PlanやApply）ごとに発行する、OpenID Connect (OIDC) 準拠の JSON Web Token (JWT) を指します。このトークンを利用することで、クラウドプロバイダー（AWS、Google Cloud、Azure など）に対して固定の秘密鍵（アクセスキーなど）を使わずに、動的な一時資格情報（Dynamic Provider Credentials）で安全に認証・リソース操作を行うことができます。

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

AWS CloudTrail Lake

この記事を書いた人

サイト管理人

コメントする

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。