Okta を Terraform で管理することで、設定のコード化による一貫性の維持と管理操作の自動化を実現できます。本記事では、Okta 用の公式 Terraform プロバイダー Terraform Okta Provider の概要や機能、現在の開発状況、基本的な使い方を紹介します。また、ユーザー管理・グループ管理・アプリケーション設定など主要なユースケースにおける Terraform 設定例について示し、最後に利用上の注意点やベストプラクティスも解説します。Okta 管理者の皆様が、Infrastructure as Code (IaC) による Okta 自動化のメリットを理解し、日々の運用に活用いただくことを目指します。
※ 本記事は Terraform Okta Provider のみにフォーカスする内容となっています。Terraform そのもののインストール手順や HCL 言語、一般的なベストプラクティスについては扱いません。Terraform の概要や基本操作を学びたい場合は、Terraform 公式ドキュメントなどをご参照ください。
Terraform Okta Providerは、Terraform から Okta (Okta Workforce Identity) を管理するためのプラグインです。Okta 上のユーザーやグループ、アプリケーションなど各種リソースをコードによるフルライフサイクル管理（作成・更新・削除）できるようになります。本プラグインを使うことで、Okta 管理者は従来の管理コンソール操作を Terraform のコード（HCL 言語）に置き換え、Okta 設定を IaC として扱うことが可能です。
Terraform Okta Provider を使用すると、ユーザーやグループの作成・更新、各種アプリ連携設定（SAML や OIDC など）、セキュリティポリシーの管理まで、Okta 管理者が通常手動で行う多くの操作をコード化して自動化できます。Terraform で管理できる Okta リソースには、以下のようなものがあります。
このように Terraform による Okta 統合管理により、Okta を含む認証基盤の構成管理が効率化され、安全性と可搬性も向上します。
Terraform Okta Providerの詳細な仕様については、以下の公式 Terraform Registry のページを参照してください。
以下の図は、Terraform Okta Provider がどのように動作するかの概略です。
この図が示すように、Terraform Okta Provider は以下の流れで動作します。
認証には API トークンまたは OAuth 2.0 を使用でき、より安全な OAuth 2.0 の使用が推奨されています。
Terraform Okta Provider は Okta の開発チームによって公式にメンテナンスされており、GitHub 上のオープンソースプロジェクトとして活発に開発が進められています。2025年7月現在、最新の安定版は v5 系のバージョン 5.2.0（2025年7月16日リリース）です。これまでに100を超えるバージョンアップが重ねられ、新機能の追加や不具合修正がアクティブに行われています。また GitHub の公開リポジトリでは130名以上のコントリビュータが参加しており、Okta の開発チームだけでなくコミュニティからの貢献も積極的に受け入れられています。
記事執筆時点で、 バージョン v6.0.0 のリリース準備がなされています。v6 系では管理対象のOkta リソース範囲がさらに拡大され、より幅広い Okta オブジェクトのサポートが予定されています。v6 系がリリースされた際には従来の v5 系は非推奨 (Deprecated) となる計画もアナウンスされています。
最新のリリース情報や変更履歴については、GitHub の CHANGELOG を確認してください。
ここからは、Terraform Okta Provider を利用する基本手順を説明します。利用には Terraform CLI （コマンドラインツール）のインストールと Okta 管理者権限を持つアカウントが必要です。また、Terraform から Okta にアクセスするための Okta API 認証情報（後述の API トークンまたは OAuth クライアント情報）を準備しておきます。
Terraform で Okta 組織を管理するための包括的なガイドは、以下の Okta Developer - Automate org management with Terraform を参照してください。
まず Terraform 設定ファイル（例: main.tf）に Okta プロバイダーの利用宣言と、接続先 Okta 情報を含むプロバイダー設定ブロックを追加します。以下のように HCL コードを記述します（Terraform 0.13 以降の利用を想定）。
terraform {
required_providers {
okta = {
source = "okta/okta"
version = "~> 5.2" # 利用するバージョン範囲（例では5.2系）
}
}
}
provider "okta" {
org_name = "hoge" # Okta org のサブドメイン名
base_url = "okta.com" # Oktaドメイン
api_token = var.okta_api_token # Okta APIトークン
}
上記では、required_providers で Okta 公式プロバイダー (okta/okta) を指定し、バージョンを 5.x 系に固定しています。これは terraform init 実行時に該当プロバイダーを自動インストールするための設定です。次に provider "okta" ブロック内で Okta org への接続情報を設定しています。
上記例では var.okta_api_token として変数参照していますが、機密情報をコード上に残さないため、実際の値は別途 .tfvars ファイルや環境変数で注入します。例えば、terraform.tfvars に以下のように記載することで実行時に値を読み込ませることができます。
org_name = "hoge"
okta_api_token = "Okta API トークン文字列"
基本設定ができたら、terraform init でプロバイダーをインストールし、terraform plan や terraform apply コマンドを実行します。Terraform が Okta org に接続し、定義されたリソースに従って Okta 上の設定を作成・変更していきます。
Terraform 用の Okta org アクセスを有効化する手順の詳細については、Okta Developer - Enable Terraform access for your Okta org を参照してください。
Terraform Okta Provider が Okta にアクセスする認証手段として、API トークン方式と OAuth 2.0（サービスアプリ方式） の2通りがあります。従来から使われてきた API トークン方式では、Okta 管理コンソールで発行した固定トークン値を API トークンとして Terraform に渡し認証します。しかし、この方法には以下の課題があります:
こうした理由から、Okta ではよりセキュアで柔軟な認可手段として OAuth 2.0 によるプロバイダー認証を推奨しています。OAuth を用いる場合、Okta 上でサービスアプリ（API アクセス用のクライアント）を作成し、Terraform プロバイダーにはそのクライアント ID・プライベートキー・スコープを設定します。サービスアプリには必要な権限を表すスコープ（例: グループ読み書きなら okta.groups.manage）を管理者が付与できます。Terraform プロバイダー側はクライアント認証情報を用いて Client Credentials フローでアクセストークンを取得し、指定のスコープ範囲内で Okta を操作します。スコープによる最小権限付与やアクセストークンの期限設定・失効が可能な点で、OAuth 認証はセキュリティ面で優れています。
Terraform Okta Provider はバージョン 4.0 以降でこの OAuth 認証方式に対応しており、プロバイダー設定に以下のような項目を指定できます。
provider "okta" {
org_name = "hoge"
base_url = "okta.com"
client_id = "Okta アプリ統合のクライアント ID"
private_key = var.okta_private_key_pem # 秘密鍵（PEM文字列やファイルパス）
scopes = ["okta.users.manage", "okta.groups.manage", "okta.apps.manage"]
}
上記の client_id とprivate_key には、Okta で作成したサービスアプリに対応する ID と RSA 秘密鍵（PEM 形式）を指定します。private_key は長い文字列になるため、コードに直接記載せず、API トークン同様に変数や環境変数経由で安全に読み込むのが良いでしょう。ファイルから読み込む場合は以下のように記述することもできます。
private_key = file("~/.okta/private-key.pem")
scopes には Terraform 実行に必要な操作権限をリストで記載します。例えばユーザーとグループの読み書きをしたい場合は "okta.users.manage" および "okta.groups.manage" を指定します（事前に Okta 上のサービスアプリに該当スコープを付与しておく必要があります）。
OAuth 認証の詳細な設定手順については、Okta Developer - Control Terraform access to Okta および Okta Developer - Implement OAuth for Okta with a service app を参照してください。
次に、Terraform Okta Provider で実現できる代表的なユースケースとして、ユーザー管理、グループ管理、アプリケーション統合設定の3つを紹介します。それぞれについて簡単な Terraform コード例と解説を示します。なお、前述の通り、ポリシーや外部 IdP 設定など他にも多様な Okta 要素を管理できますが、本記事では代表的な例に絞って解説します。
実践的な使用例とベストプラクティスについては、GitHub のサンプルコード集も参考になります。
Okta ユーザーのライフサイクル管理は Terraform Okta Provider の基本機能の一つです。okta_user リソースを使うことで、新規ユーザーの作成、既存ユーザーのプロファイル更新、削除（無効化）までをコードで管理できます。
例えば、新規ユーザーを1名作成する Terraform コードは次のようになります。
resource "okta_user" "example_user" {
first_name = "Taro"
last_name = "Nekumo"
email = "taro.nekumo@example.com"
login = "taro.nekumo@example.com"
}
上記では、名・姓・メールアドレス・ログイン名（通常メールアドレスと同じ）の基本属性を指定しています。この定義を terraform apply すれば、Okta 上に Taro Nekumo というユーザーが作成されます。パスワード設定や有効化タイミングは Okta 側ポリシー（デフォルトでは招待メール送信や初回ログイン時に設定）に依存しますが、okta_user リソースで password 属性や activate フラグを指定して Terraform から柔軟に制御することも可能です。また okta_user ではカスタムプロファイル属性の設定や、グループメンバーシップ（別途リソースで管理）なども扱えます。
複数のユーザーをまとめてコード管理することも容易です。Terraform の for_each や count メタ引数を利用すれば、ユーザー情報のリストから動的に複数の okta_user リソースを生成できます。これにより大量のユーザーアカウントを一括管理したり、新入社員アカウントの自動作成を行うことも可能です。
okta_user リソースの詳細な仕様については、Terraform Registry - okta_user を参照してください。
Okta でユーザーを整理し権限付与する単位であるグループも、Terraform で自動化できます。okta_group リソースでグループの作成や説明文設定を行い、さらに okta_group_membership リソースでユーザーとグループの所属関係をコードで定義できます。
まず、新しいグループを作成する Terraform コード例です。
resource "okta_group" "example_group" {
name = "sales_div"
description = "Sales Division"
}
上記を適用すると、名前 developers-team の Okta グループが作成されます。description はグループの説明文として Okta 管理画面に表示されます。
次に、このグループに特定のユーザーを参加させるには okta_group_membership リソースを使用します。例えば、先ほどの example_user を example_group に追加するには以下のように記述します。
resource "okta_group_membership" "example_membership" {
group_id = okta_group.example_group.id # グループのID（他リソース参照）
user_id = okta_user.example_user.id # ユーザーのID（他リソース参照）
}
group_id や user_id には、それぞれ対象となるグループ・ユーザーの Terraform リソース参照（.id属性）を指定しています。Terraform の依存関係解析により、このメンバーシップリソースは対応するユーザーおよびグループの作成後に処理され、Okta 上でユーザーがそのグループに割り当てられます。
多数のユーザーを一度にグループへ追加する場合、個別に okta_group_membership を並べる代わりに、okta_user_group_memberships リソースを使って一つのリソースで複数所属を管理する方法もあります。以下は一人のユーザーを複数のグループに所属させる例です。
resource "okta_user_group_memberships" "user_memberships" {
user_id = okta_user.example_user.id
groups = [
okta_group.example1_group.id,
okta_group.example2_group.id
]
}
ユーザー数が少ない場合は for_each で okta_group_membership を個別に作成しても問題ありませんが、数十人以上などより多くのユーザーを管理する場合は okta_user_group_memberships を使用することで、コードの可読性と保守性が向上します。
なお、Terraform Okta Provider にはグループルール（okta_group_rule リソース）も提供されています。グループルールを使うと、ユーザープロファイル属性に基づき自動でグループ振り分けを行う条件を定義できます。例えば「部署属性が Engineering のユーザーを自動で Developers グループに追加する」等のルールをコード化でき、管理コンソールで手動設定する場合に比べ一括管理や複製展開が容易になります。グループルールも Terraform で定義・更新できるため、組織ポリシー変更時にコード修正して再適用するだけで条件を一括更新可能です。
okta_group リソースの詳細な仕様については、Terraform Registry - okta_groupを参照してください。
最後に、アプリケーション（いわゆる「アプリ統合」）の設定管理です。Okta におけるアプリ統合とは、社内外のサービスを Okta 経由でシングルサインオン (SSO) させるための連携設定や、Okta を認証サーバーとして利用するための構成を指します。Terraform Okta Provider ではさまざまな種類のアプリケーションに対応するリソースが用意されており、SAML や OIDC (OAuth2) といったプロトコル別にリソースタイプが存在します（例: okta_app_saml, okta_app_oauth など）。
SAML アプリケーションの例として、外部 SaaS ExampleApp を Okta で SAML 2.0 連携する設定を Terraform コードで構築してみましょう。以下は okta_app_saml リソースによる SAML アプリ定義の一例です。
resource "okta_app_saml" "example_app" {
label = "ExampleApp"
sso_url = "<https://example.com/saml/sso>"
recipient = "<https://example.com/saml/sso>"
destination = "<https://example.com/saml/sso>"
audience = "<https://example.com/saml/metadata>"subject_name_id_template = "$${user.userName}"
subject_name_id_format = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
signature_algorithm = "RSA_SHA256"
digest_algorithm = "SHA256"
attribute_statements {
type = "GROUP"
name = "groups"
filter_type = "REGEX"
filter_value = ".*"
}
}
この設定により、Okta 上にカスタム SAML アプリ ExampleApp が作成されます。必要な ACS (Assertion Consumer Service) URLやオーディエンス（対象者）といったサービスプロバイダー側情報、および SAML トークンに関する各種設定（署名アルゴリズム等）を指定していることが分かります。また attribute_statements ブロックでは、SAML アサーションに含める属性としてユーザーのグループ情報（全グループ名）を送信する設定を加えています。Terraform で適用後、Okta 側ではこのアプリのメタデータ（Issuer や証明書など）が生成されるため、それをサービス側（example.com 側）に取り込んで設定することで SSO が機能するようになります。
okta_app_saml リソースの詳細な仕様については、Terraform Registry - okta_app_saml を参照してください。
OIDC/OAuth アプリケーションも Terraform で管理可能です。例えば Okta を認証サーバーとして使用するシングルページアプリケーション (SPA) を登録する場合、okta_app_oauth リソースでクライアント情報を作成します。概略コードは次のとおりです。
resource "okta_app_oauth" "spa_app" {
label = "Example Single Web Application App"
type = "browser"
grant_types = ["authorization_code"]
redirect_uris = ["https://example.com/callback"]
response_types = ["code"]
}
このように、アプリの種類（type が web/browser/native 等）や使用する OAuth2 フロー（grant_types や response_types）、リダイレクト URI 等を Terraform コードで記述できます。適用すると Okta 上にクライアント ID やクライアントシークレット（該当タイプの場合）が発行され、アプリケーション開発者はそれを用いて Okta による認証を実装できます。
okta_app_oauth リソースの詳細な仕様については、Terraform Registry - okta_app_oauth を参照してください。
さらに、Okta アプリのユーザー・グループへの割り当ても Terraform で設定可能です。例えば、okta_app_group_assignment リソースを使うことで、特定のアプリに特定のグループを割り当てる設定をコード化できます。例えば「社内アプリ A は開発チームのグループ (developers) にのみ割り当てる」といったポリシーも Terraform コード上で表現できます。適用すれば該当グループ所属の全ユーザーにそのアプリが有効化され、一括で利用許可を付与できます。
以上のように、ユーザー・グループ・アプリケーションといった Okta の主要コンポーネントはTerraform で定義・管理することができます。これらを組み合わせれば Okta を含むアイデンティティ基盤全体をコードベースで構築でき、環境構築の再現性確保や大規模運用時の自動化を推進できるでしょう。
最後に、Terraform Okta Provider を活用する上で覚えておきたいポイントやベストプラクティスをまとめます。
本稿では、Terraform Okta Provider を活用した Okta 環境管理の概要と簡単なユースケース、さらに活用する際の重要なポイントを紹介しました。Terraform による IaC 導入には初期段階で準備が必要ですが、一度仕組みを整えれば、アイデンティティ管理における日常業務の負荷軽減とヒューマンエラーの防止に大きく貢献します。Okta と Terraform の連携がもたらす効率的かつ安全なアイデンティティ管理基盤を、ぜひ皆様の環境にも導入してみてください。
各リソースの詳細設定については、公式の Terraform Registry ドキュメントや Okta Developer サイトのガイドが参考になります。また、Okta と Terraform の統合に関する背景や利点については、Okta公式ブログ記事 も参照してください。
本記事が皆様の Okta 管理の効率化の一助となれば幸いです。