WordPressでSSO（シングルサインオン）を実現するプラグインの選び方と比較

WordPressにSSO（シングルサインオン）を導入すると、Microsoft Entra ID、Google Workspace、Oktaなどの社内IDでそのままログインできるようになり、退職者のアカウント停止もIdP側の操作だけで済みます。プラグイン選びで最初に決めるべきなのは製品名ではなく、IdPが対応しているプロトコルがSAML 2.0かOpenID Connect（OIDC）かです。この記事では、両プロトコルの違い、代表的なプラグインの位置づけ、選定時に確認すべき項目、導入時に締め出しを防ぐ手順を説明します。

SSOの基本: IdPとSP、2つのプロトコル

SSOでは、ユーザーの本人確認を行う側を IdP（Identity Provider）、IdPの判断を信用してログインさせる側を SP（Service Provider） と呼びます。WordPressはSPの立場で、プラグインがIdPとのやり取りを担当します。

• SAML 2.0: XMLの署名付きメッセージで認証結果を受け渡す方式です。企業向けのIdPのほとんどが対応しており、社内ポータルの一部としてWordPressを使う場合によく選ばれます。SP側では、エンティティID、ACS URL（認証結果を受け取るURL）、IdPの証明書などを設定します。
• OpenID Connect（OIDC）: OAuth 2.0の上に本人確認の仕組みを載せた方式で、JSONとトークンでやり取りします。設定はクライアントID、クライアントシークレット、リダイレクトURIが中心で、SAMLよりも項目が少なく済む傾向があります。

どちらが優れているというより、使いたいIdPがどちらに対応しているか、社内で既に運用している連携方式はどちらかで決めるのが現実的です。多くのIdPは両方に対応しているため、迷う場合は社内の他システムと同じ方式に揃えると、運用担当者の負担が減ります。

なお、Googleアカウントやソーシャルアカウントでのログインを追加する「ソーシャルログイン」もOAuth/OIDCを使いますが、目的は一般利用者の登録の手間を減らすことです。社員や関係者のアクセス管理を目的とするSSOとは、選ぶプラグインも設定の考え方も異なります。

代表的なプラグインの位置づけ

WordPress公式ディレクトリには、SSO用のプラグインが多数あります。ここでは方向性の異なる代表例を挙げます。機能の範囲や無料版で使える範囲は更新で変わるため、導入前に各プラグインのページと最新の説明を確認してください（2026年10月現在）。

この表は機能の優劣ではなく、設定の考え方の違いを示すものです。たとえば、ロールの自動割り当てや複数IdPへの対応がどのプラグインのどの版で使えるかは、版によって異なる可能性があるため、要件に照らして個別に確認する必要があります。

マルチサイト環境や、非常に大規模な組織での利用では、WordPress単体のプラグインではなく、リバースプロキシやIDaaS側の機能で認証をまとめる構成が選ばれることもあります。

選定時に確認すべき項目

プラグインの比較では、次の観点を順に確認すると判断がぶれにくくなります。

1. 使いたいIdPとプロトコルに対応しているか: IdP名が明記されていなくても、標準的なSAML 2.0やOIDCに準拠していれば接続できることは多いです。ただし、IdPごとの設定例があると導入が楽になります。
2. ユーザーの自動作成（JITプロビジョニング）: 初回ログイン時にWordPress側のユーザーを自動で作るか、事前に作ったユーザーとメールアドレスで紐づけるかを選べるか。
3. 属性とロールの対応づけ: IdPから受け取るメールアドレス・氏名・グループ情報を、WordPressのユーザー情報やロール（編集者、投稿者など）に対応させられるか。社員の異動を権限に反映したい場合は重要です。
4. 通常ログインとの併用: SSOを必須にするか、従来の wp-login.php でのログインも残すかを設定できるか。障害時の非常口として、ローカルの管理者ログインを残せるかは大きなポイントです。
5. シングルログアウト（SLO）: IdPからログアウトしたときにWordPress側のセッションも終了させたいか。必要なら対応状況を確認します。
6. 保守状況: 最終更新日、検証済みのWordPressバージョン、サポートフォーラムでの対応状況。認証を担うプラグインは、更新が止まると脆弱性の影響が大きくなります。
7. 署名と証明書の扱い: SAMLでは、署名の検証が既定で有効になっているか、IdPの証明書を更新するときの手順がどうなるかを確認します。証明書の期限切れは、ある日突然全員がログインできなくなる典型的な原因です。

導入の流れ（SAMLの場合）

SAMLを例に、一般的な導入手順を示します。OIDCでも、「IdPにWordPressを登録し、WordPress側にIdPの情報を設定する」という流れは同じです。

1. バックアップとテスト環境の用意: データベースとファイルのバックアップを取り、可能ならステージング環境で先に試します。
2. ローカルの管理者アカウントを確認: SSOで問題が起きても入れるよう、SSOを経由しない管理者アカウントのログイン情報を控えておきます。
3. IdPにWordPressを登録: プラグインが表示するSP側のエンティティIDとACS URLをIdPに登録します。SPのメタデータを出力できるプラグインなら、それを読み込ませると入力ミスを防げます。
4. WordPressにIdPの情報を設定: IdPのエンティティID、ログインURL、署名用の証明書を設定します。IdPのメタデータXMLを読み込める場合はそれを使います。
5. 属性の対応づけ: メールアドレスをユーザーの照合キーにするのが一般的です。ユーザー名（user_login）は後から変更できないため、何を入れるかを最初に決めておきます。
6. 権限の低いユーザーでテスト: 最初は投稿者などのテスト用アカウントでログインし、ユーザーが正しく作成・紐づけされるか、ロールが意図どおりかを確認します。
7. 本番の切り替え: 問題がなければ管理者もSSOでログインするようにし、必要に応じて通常ログインを制限します。

SSO導入後に締め出されたときの対処

IdP側の障害、証明書の期限切れ、設定ミスなどで、SSOを経由したログインが全員できなくなることがあります。そのときのために、次の手段を事前に確認しておきます。

• WP-CLIでプラグインを一時停止: wp plugin deactivate plugin-slug でSSOプラグインを停止すると、通常の wp-login.php でのログインに戻ります。
• FTPでプラグインのフォルダ名を変更: WP-CLIが使えない場合は、wp-content/plugins/ 内の該当フォルダ名を一時的に変えると、WordPressはそのプラグインを停止扱いにします。
• ローカル管理者でログイン: プラグインが通常ログインの併用を許している場合は、控えておいた管理者アカウントでログインし、設定を見直します。

これらの手順を、導入時の作業手順書に書いておくことをおすすめします。SSOを入れた担当者以外でも復旧できる状態にしておくのが理想です。

まとめ

• SSOプラグイン選びは、まずIdPが対応するプロトコル（SAML 2.0かOIDC）を決めることから始めます。
• 代表的な選択肢には、コードで管理する開発者向けのもの、汎用のOIDCクライアント、管理画面で設定できる多機能なものがあり、機能の範囲は版によって異なります。
• 比較では、ユーザーの自動作成、ロールの対応づけ、通常ログインとの併用、保守状況、証明書の扱いを確認します。
• 導入はバックアップとローカル管理者の確保から始め、権限の低いアカウントでテストしてから本番に切り替えます。
• 締め出しに備え、WP-CLIやFTPでプラグインを停止する手順を事前に用意しておきます。

• WordPressにFacebook・Twitterのソーシャルログインを導入する方法
• WordPressでリスクベース認証を導入する方法