WordPressとOktaの連携方法：OIDCでSSOを設定し、グループを権限に対応させる

Okta は、社員や取引先のアカウント・多要素認証・アプリへのアクセス権をまとめて管理する IDaaS（Identity as a Service）です。WordPress を Okta とつなぐと、利用者は Okta のアカウントで WordPress にログインでき、退職者のアカウントを Okta で止めれば WordPress にも入れなくなります。この記事では、OpenID Connect（OIDC）でつなぐ方法を、Okta 側のアプリ作成、WordPress 側のプラグイン設定、Okta のグループを WordPress の権限グループに対応させるコードの順に説明します（画面の名前は2026年11月時点のものです）。

構成の選び方：OIDC と SAML

WordPress と Okta をつなぐ方法は主に2つです。

• OIDC：WordPress.org で公開されている「OpenID Connect Generic Client」など、特定の IdP に依存しないプラグインで設定できます。この記事はこちらを使います。
• SAML 2.0：「SAML Single Sign On – SSO Login」（miniOrange）や「OneLogin SAML SSO」など、SAML のプラグインを使います。社内で SAML に統一している場合はこちらを選びます。

どちらのプラグインを選ぶ場合も、最終更新日・検証済みの WordPress のバージョン・サポートフォーラムの状況を確認し、ステージング環境で試してから本番に入れてください。

以前の版のこの記事に載せていた okta apps add や wp okta sso のようなコマンド、「Okta SSO for WordPress」というプラグインは確認できなかったため削除しました。Okta 側の設定は管理画面（Admin Console）で行います。

始める前に

• サイトのファイルとデータベースのバックアップを取る
• 通常のパスワード（と2要素認証）でログインできる非常用の管理者アカウントを1つ残す
• FTP / SFTP か WP-CLI で、プラグインを無効化できることを確かめる
• サイトを HTTPS で公開する

手順1：Okta に OIDC アプリを作る

Okta の Admin Console で次のように操作します。

1. 「Applications and Resources」→「Applications」を開く（画面の版によっては「Applications」→「Applications」）
2. 「Create App Integration」を押す
3. Sign-in method で「OIDC - OpenID Connect」、アプリの種類で「Web Application」を選んで「Next」
4. 次の項目を入力して保存する

example.com は自分のサイトのドメインと WordPress のパスに置き換えます。保存すると、「General」タブの「Client Credentials」に Client ID が表示されます。クライアント認証の方式で「Client secret」を選ぶと Client secret を発行・表示できます。シークレットはパスワードと同じ扱いで、チャットやチケットに貼らないでください。

割り当て（Assignments）は、WordPress にログインできる人を絞る一番確実な方法です。「Everyone」に割り当てたままにすると、Okta のアカウントを持つ全員がログインを試せます。

手順2：グループの情報を ID トークンに含める（権限を対応させる場合）

Okta のグループで WordPress の権限グループを決めたい場合は、グループの情報を渡す設定をします。

1. 作成したアプリを開き、「Sign On」タブの「OpenID Connect ID Token」で「Edit」を押す
2. Group claim type は「Filter」のまま、Group claims filter の名前を groups にする
3. 条件を「Matches regex」にして、渡したいグループに合う正規表現を入れる（例: WordPress 用のグループだけなら ^wp-.*）
4. 保存する

WordPress 側では、スコープに groups を加えてリクエストします。必要なグループだけが渡るよう、.*（全グループ）より絞った条件にするのが安全です。

手順3：発行者（issuer）とエンドポイントを確認する

Okta には、組織に最初からある org authorization server と、API を守るために作る custom authorization server があります。WordPress へのログインに使うだけなら org authorization server で足ります。custom authorization server は API Access Management という追加機能が必要です。

{yourOktaDomain} は自社の Okta のドメインに置き換えます。ブラウザかコマンドでディスカバリー文書を開き、各エンドポイントの URL を確認しておきます。

# example.okta.com は自社の Okta ドメインに置き換える
curl -s https://example.okta.com/.well-known/openid-configuration | python3 -m json.tool

手順4：WordPress に OpenID Connect Generic Client を設定する

「プラグイン」→「新規追加」で「OpenID Connect Generic Client」をインストールして有効化し、「設定」→「OpenID Connect Generic」を開きます。

1. 画面上部の「Quick Setup: Import from Discovery Document」に、手順3のディスカバリー文書の URL を入れて読み込む
2. 次の項目を入力して「変更を保存」を押す

新しく作られるユーザーの権限は「設定」→「一般」の「新規ユーザーのデフォルト権限グループ」になります。「購読者」になっているか確認してください。クライアントシークレットを wp-config.php の定数（OIDC_CLIENT_SECRET）で渡す方法や、各項目の詳しい意味は、関連記事の「WordPressのOpenID Connect（OIDC）連携」で説明しています。

この状態でログイン画面に「Login with OpenID Connect」ボタンが出るので、割り当てたテスト用のアカウントでログインできるか確かめます。

手順5：Okta のグループを WordPress の権限グループに対応させる

プラグイン自体には、グループと権限グループを対応させる設定はありません。代わりに、ログインのたびに呼ばれる openid-connect-generic-update-user-using-current-claim アクションを使います。次のコードを wp-content/mu-plugins/okta-role-map.php として保存すると、ログインのたびに groups クレームを見て権限グループを設定します。

<?php
/**
 * Plugin Name: Okta groups to WordPress roles
 * Description: OpenID Connect Generic Client で受け取った groups クレームから権限グループを設定する。
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

add_action(
	'openid-connect-generic-update-user-using-current-claim',
	function ( $user, $user_claim ) {
		if ( ! ( $user instanceof WP_User ) || ! is_array( $user_claim ) ) {
			return;
		}
		// 管理者の権限は自動では変えない（WordPress 側で人が管理する）。
		if ( in_array( 'administrator', (array) $user->roles, true ) ) {
			return;
		}
		$groups = ( isset( $user_claim['groups'] ) && is_array( $user_claim['groups'] ) ) ? $user_claim['groups'] : array();

		// Okta のグループ名 => WordPress の権限グループ（上にあるものを優先）。
		$map = array(
			'wp-editors' => 'editor',
			'wp-authors' => 'author',
		);
		$role = 'subscriber';
		foreach ( $map as $group => $mapped_role ) {
			if ( in_array( $group, $groups, true ) ) {
				$role = $mapped_role;
				break;
			}
		}
		if ( array( $role ) !== array_values( (array) $user->roles ) ) {
			$user->set_role( $role );
		}
	},
	10,
	2
);

このコードの動きは次のとおりです。

• wp-editors グループの人は「編集者」、wp-authors グループの人は「投稿者」、どちらでもない人は「購読者」になる
• 管理者の権限は変えない。管理者を Okta のグループで自動的に増やすと、Okta 側の設定ミスがそのままサイトの乗っ取りにつながるため、管理者は WordPress 側で人が管理する
• グループから外れた人は、次のログインで「購読者」に戻る

グループ名は自社の Okta に合わせて変えてください。プラグインは、ユーザー情報のエンドポイントを設定していればそこから、設定していなければ ID トークンからクレームを受け取ります。groups が届いているかは、プラグインの「Enable Logging」を一時的に有効にするか、テスト用ユーザーで確かめます。

手順6：テストと本番切り替え

ステージングで次を確かめます。

• 割り当てたユーザーはログインでき、割り当てていないユーザーは Okta の画面で止められるか
• グループに応じて、想定した権限グループになるか
• Okta でアカウントを無効にすると、次のログインができなくなるか
• WordPress からログアウトしたとき、Okta のセッションも終わるか（Sign-out redirect URIs の登録が必要）

WordPress のログイン状態は WordPress の Cookie で保たれるため、Okta でアカウントを止めても、すでにログイン中のセッションはすぐには切れません。退職者などをすぐに締め出したい場合は、WordPress の「ユーザー」画面で該当ユーザーのプロフィールを開き、「すべての場所からログアウト」を使います。

動作を確かめたら、Login Type を自動転送（Auto Login - SSO）に切り替えるかを決めます。自動転送にすると、ログイン画面を開いた時点で Okta へ転送されます。

うまくいかないとき

• Okta の画面に redirect_uri のエラーが出る：Sign-in redirect URIs の値と、プラグインが送る URL が一字一句同じか確認します。
• 「このアプリに割り当てられていない」と表示される：Okta の Assignments で、そのユーザーかグループを割り当てます。
• 権限グループが変わらない：スコープに groups が入っているか、Group claims filter の条件にグループ名が合っているか、コードのグループ名と一致しているかを確認します。
• 締め出された：FTP / SFTP でプラグインのフォルダー名を変えるか、WP-CLI で無効化します。

wp plugin deactivate daggerhart-openid-connect-generic

まとめ

• Okta の Admin Console で「OIDC - OpenID Connect」の「Web Application」を作り、リダイレクト URI と割り当てを設定する
• WordPress へのログインだけなら org authorization server で足り、エンドポイントはディスカバリー文書から読み込む
• グループを使う場合は ID トークンに groups を含め、openid-connect-generic-update-user-using-current-claim で権限グループを設定する
• 管理者権限は自動で与えず、非常用の管理者とプラグインの無効化手段を残しておく

• WordPressのOpenID Connect（OIDC）連携：OpenID Connect Generic Clientの設定手順
• WordPressでOpenID Connect（OIDC）を使ったSSOを設定する手順
• WordPressのログインセキュリティを強化する方法