WordPressでOpenID Connect（OIDC）のSSOを設定する手順と注意点

WordPress に OpenID Connect（OIDC）のシングルサインオン（SSO）を入れるなら、暗号処理を自作せず、保守されている OIDC クライアントプラグインを使い、社内の ID プロバイダー（IdP）に WordPress を「アプリ」として登録するのが基本です。この記事では、IdP 側の登録、プラグインの設定、ユーザーの紐付け方、締め出されないための復旧経路、本番切り替え前の確認までを順に説明します。

OIDC の SSO で何が起きているか

OIDC は OAuth 2.0 の上に「誰がログインしたか」を伝える仕組みを足した規格です。WordPress のログインでよく使われるのは認可コードフローで、流れは次のとおりです。

1. ユーザーが WordPress のログインボタンを押すと、IdP（Microsoft Entra ID、Google Workspace、Okta、Keycloak など）のログイン画面へ転送される
2. IdP で認証すると、WordPress の「リダイレクト URI」に認可コード付きで戻ってくる
3. WordPress がサーバー間通信でコードをトークンに交換し、ID トークンやユーザー情報から本人を特定する
4. 対応する WordPress ユーザーでログイン状態（認証 Cookie）を作る

パスワードは IdP 側だけが扱い、WordPress には届きません。退職者のアカウントを IdP で止めれば WordPress にも入れなくなる、多要素認証を IdP 側で一元管理できる、というのが導入の主な理由です。

準備：始める前に決めておくこと

作業前にサイトのファイルとデータベースのバックアップを取り、ステージング環境で一通り試してから本番に入れてください。認証まわりは設定を誤るとログインできなくなるため、次の3点を先に決めておくと迷いません。

• 誰を SSO の対象にするか：管理者だけか、編集者や会員まで含めるか
• ユーザーをどう紐付けるか：既存の WordPress ユーザーと結び付けるのか、初回ログイン時に新規作成するのか
• 非常口を残すか：IdP が止まったときに使う、通常パスワードで入れる管理者アカウントを1つ残すか（残すことを勧めます）

手順1：IdP にアプリを登録する

IdP の管理画面で「Web アプリケーション」としてクライアントを登録します。画面の名称は IdP ごとに違いますが、決める内容は共通です。

• リダイレクト URI：プラグインが指定する URL を一字一句そのまま登録します。末尾のスラッシュ、http と https、www の有無が違うだけで失敗します
• スコープ：openid email profile が一般的です
• クライアント ID とクライアントシークレット：WordPress 側に設定します。シークレットはパスワードと同じ扱いで、チャットやチケットに貼らないでください

OpenID Connect Generic Client を使う場合、リダイレクト URI は公式の説明で次のとおりです（example.com は自分のサイトに置き換えます）。

クエリ文字列付きの URI を受け付けない IdP では、Alternate Redirect URI を使います。

多くの IdP はディスカバリー文書（/.well-known/openid-configuration）を公開しており、ここに認可・トークン・ユーザー情報・ログアウトの各エンドポイントが載っています。URL の打ち間違いを防ぐため、まず中身を確認しておきます。

# 例: Google のディスカバリー文書から必要なエンドポイントを確認する
curl -s https://accounts.google.com/.well-known/openid-configuration | python3 -m json.tool

# Microsoft Entra ID の場合（{tenant} はテナント ID に置き換える）
curl -s https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration | python3 -m json.tool

手順2：WordPress に OIDC クライアントプラグインを入れる

代表的な選択肢は次の2つです（2026年10月時点）。

• OpenID Connect Generic Client（スラッグ daggerhart-openid-connect-generic）：特定の IdP に依存しない汎用クライアント。設定項目が OIDC の用語そのままなので、仕組みが分かっている人には扱いやすい
• miniOrange の OAuth / OpenID Connect 系プラグイン：主要 IdP 向けの設定ガイドが揃っている。無料版と有償版で使える機能が分かれているため、必要な機能（ロールの自動割り当てなど）がどちらにあるかを公式ページで確認してください

ほかにも IdP ベンダー自身が WordPress 用プラグインを出していることがあります。どれを選ぶ場合も、最終更新日、対応している WordPress のバージョン、サポートフォーラムの反応を見て、保守が続いているものを選んでください。

OpenID Connect Generic Client は、WP-CLI では次のように入れます。

wp plugin install daggerhart-openid-connect-generic --activate

設定画面（「設定」メニュー内の OpenID Connect Generic Client の画面）で入力する主な項目は次のとおりです。ラベルは英語表記のことがあります。

最初は Login Type を「ログイン画面にボタンを出す」方式にしてください。自動転送にすると、設定ミスがあった時点で通常ログインの画面に戻れなくなります。

このプラグインは、クライアント ID やシークレットを wp-config.php の定数で渡すこともできます。定数で指定すると、データベースのダンプやバックアップに秘密情報が残りにくくなります。

<?php
// wp-config.php の「編集はここまで」より上に追加する（値は IdP で発行されたものに置き換える）
define( 'OIDC_CLIENT_ID', 'your-client-id' );
define( 'OIDC_CLIENT_SECRET', 'your-client-secret' );
define( 'OIDC_CLIENT_SCOPE', 'openid email profile' );

手順3：ユーザーの紐付け方を決める

SSO で最も事故が起きやすいのがここです。

ユーザーの識別の基本は sub クレームです。sub は IdP がユーザーごとに発行する変わらない ID で、メールアドレスのように変更や再利用が起きません。OpenID Connect Generic Client も、一度紐付いたユーザーは IdP から受け取った識別子をユーザーメタに保存し、次回からはそれで照合します。

注意が要るのは初回の紐付けです。このプラグインで「Link Existing Users」を有効にすると、既存ユーザーとの照合は既定でメールアドレスで行われます（「Identify with User Name」を有効にするとユーザー名で照合）。IdP がメールの所有確認をしていない場合、他人のメールアドレスを名乗ったアカウントで既存の管理者に成り代われる危険があります。メールで紐付けるのは、自社が管理する IdP で、メールの確認済み状態（email_verified など）が保証される場合に限ってください。

新規ユーザーの自動作成を有効にする場合、このプラグインは作成時にロールを指定せず、WordPress の「設定」→「一般」の「新規ユーザーのデフォルト権限グループ」が使われます。ここを「購読者」など最小限にしておきます。IdP のグループに応じて編集者や管理者を割り当てるプラグインもありますが、最初は自動で管理者権限を与えず、権限昇格は WordPress 側で人が行う運用が安全です。

また、SSO で作られたユーザーの氏名やメールアドレスは個人データとして WordPress に保存されます。どの情報を取得して何に使うかをプライバシーポリシーに書き、不要なクレーム（電話番号など）はスコープに含めないでください。

手順4：締め出されないための復旧経路を用意する

設定変更の前に、次の非常口が使えることを確かめておきます。

• 通常パスワード（と二要素認証）でログインできる管理者アカウントを1つ残す
• FTP / SFTP かファイルマネージャーで wp-content/plugins/ にアクセスできる
• 可能なら WP-CLI が使える

SSO が原因でログインできなくなったら、プラグインのフォルダ名を一時的に変更するか、WP-CLI で無効化すれば通常ログインに戻れます。

# 有効なプラグインのスラッグを確認してから無効化する
wp plugin list --status=active
wp plugin deactivate daggerhart-openid-connect-generic

非常用アカウントはパスワードを長く複雑にし、二要素認証をかけ、ログイン試行回数の制限も有効にしておきます。SSO を入れても、通常ログインの入口が残る限りそこは攻撃対象です。

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

ステージングで、少なくとも次のケースを確認してください。

• 既存ユーザーが SSO でログインし、同じ WordPress ユーザーとして扱われるか（別ユーザーが重複作成されないか）
• 新規ユーザーが想定したロールで作成されるか
• IdP 側でアカウントを無効にしたユーザーが入れなくなるか
• WordPress からログアウトしたとき、IdP のセッションも終了させるか（End Session Endpoint の設定次第で挙動が変わります）
• ログイン後、元のページに戻るか

うまくいかないときは、まずリダイレクト URI の不一致を疑います。IdP のエラー画面に「redirect_uri が一致しない」旨が出ていれば、登録値とプラグインが送っている値を見比べてください。次に多いのがサーバーの時刻ずれで、ID トークンの有効期限の検証に失敗します。サーバーの時刻同期（NTP）が有効か確認してください。キャッシュ系プラグインや CDN がコールバック URL をキャッシュしている場合も失敗するので、該当 URL はキャッシュ対象から外します。

プラグインのログ機能（OpenID Connect Generic Client では「Enable Logging」）を有効にすると原因が追いやすくなりますが、ログにトークンやユーザー情報が含まれることがあります。調査が終わったら無効にし、記録されたログを削除してください。

まとめ

• OIDC の SSO は保守されているクライアントプラグインで実装し、暗号処理は自作しない
• IdP にはプラグインのリダイレクト URI を正確に登録し、エンドポイントはディスカバリー文書で確認する
• 識別は sub が基本。既存ユーザーとのメールでの紐付けは、確認済みメールが保証される IdP に限る
• 自動作成ユーザーのロールは既定の権限グループで最小限にし、取得する個人データはプライバシーポリシーに明記する
• 通常ログインの非常用管理者とプラグイン無効化の手段を残してから切り替える

関連記事:

• WordPressのログインセキュリティを強化する方法
• WordPressに二要素認証を導入する方法