社内で Microsoft Entra ID（旧 Azure AD）や Google Workspace、Okta などの ID 基盤を使っているなら、WordPress のログインを SAML 2.0 で連携させることで、社員は会社のアカウントでそのまま管理画面に入れるようになります。退職者のアカウント停止も ID 基盤側の操作だけで済みます。この記事では、WordPress に SAML のシングルサインオン（SSO）を導入するときの全体像、ID 基盤と WordPress の双方で設定する項目、ログインできないときに確認すべきポイントを解説します。
SAML SSOの仕組みと用語
SAML 連携では、役割の異なる2つのシステムが登場します。
- IdP（Identity Provider）: 利用者を認証する側。Entra ID、Google Workspace、Okta など
- SP（Service Provider）: 認証結果を受け取ってログインさせる側。ここでは WordPress
ログインの流れは次のとおりです。利用者が WordPress のログインボタンを押すと IdP の画面に転送され、会社のアカウントで認証します。認証に成功すると、IdP は署名付きの「アサーション」を利用者のブラウザ経由で WordPress に POST し、WordPress はその署名を検証して、該当するユーザーとしてログインさせます。
設定でやり取りする主な値は次の4つです。どちらの画面にどの値を入れるのかを取り違えるのが、最も多いつまずきです。
- エンティティ ID（Entity ID / Issuer）: SP と IdP をそれぞれ識別する文字列。URL 形式が多い
- ACS URL（Assertion Consumer Service URL）: IdP がアサーションを送る WordPress 側の受け口
- SSO URL（シングルサインオン URL）: WordPress が利用者を転送する IdP 側のログイン URL
- X.509 証明書: IdP が署名に使う証明書。WordPress 側はこれで署名を検証する
導入前に決めておくこと
WordPress のコアには SAML 機能がないため、プラグインで実装します。プラグインを入れる前に、運用面で次の点を決めておくと設定がぶれません。
- 既存ユーザーとの対応付け: WordPress のユーザーと IdP のアカウントを何で突き合わせるか。多くの場合はメールアドレスです。既存ユーザーのメールアドレスが会社のアドレスと一致しているかを事前に確認します。
- 初回ログイン時の自動作成: IdP で認証できた人を、WordPress に未登録でも自動でユーザー作成するか。作成する場合、初期の権限グループを何にするか。
- 権限の割り当て: IdP のグループ属性を使って「編集者」「管理者」を自動で割り当てるか、WordPress 側で手動で管理するか。
- 緊急用ログイン: IdP の障害や証明書の期限切れで SSO が使えなくなったときに入れる、ローカルの管理者アカウントを残すか。
4 の緊急用アカウントは、残すことを強くおすすめします。SSO しか入口がない状態で IdP 側の設定を誤ると、誰も管理画面に入れなくなります。
プラグインを選ぶ
WordPress で SAML を扱う代表的なプラグインには、次のようなものがあります。
- WP SAML Auth: Pantheon が公開しているプラグイン。PHP の SAML ライブラリを利用し、設定画面またはコード（フィルター）で構成する
- OneLogin SAML SSO: OneLogin の SAML ライブラリを使ったプラグイン。IdP は OneLogin に限らず利用できる
- SAML Single Sign On – SSO Login（miniOrange）: 主要 IdP ごとの設定ガイドがある。属性やロールの対応付けなど一部機能は有料版の範囲
各プラグインの機能範囲、無料版でできること、更新頻度は変わることがあります（2026年10月現在）。導入前に WordPress.org のプラグインページで、最終更新日、対応している WordPress のバージョン、サポートフォーラムの対応状況を確認してください。認証を担うプラグインは、更新が止まると重大なリスクになります。
なお、IdP が OpenID Connect（OIDC）に対応している場合は、SAML ではなく OIDC 対応のプラグインを使う選択肢もあります。証明書の更新作業がない分、運用が簡単になることがあります。
設定の手順
ここでは一般的な流れを説明します。画面の名称や項目名はプラグインや IdP によって異なるので、各製品のドキュメントと照らし合わせながら進めてください。作業は本番ではなくステージング環境で行い、事前にデータベースとファイルのバックアップを取っておきます。
1. WordPress側でSP情報を確認する
プラグインを有効化すると、設定画面に WordPress 側のエンティティ ID と ACS URL が表示されるか、SP メタデータ（XML）をダウンロードできるようになります。この2つを控えておきます。
2. IdP側にアプリケーションを登録する
IdP の管理画面で、カスタムの SAML アプリケーションを作成します。
- Entra ID では、「エンタープライズ アプリケーション」で独自のアプリケーションを作成し、シングルサインオンの方式として SAML を選びます。「識別子（エンティティ ID）」に WordPress のエンティティ ID、「応答 URL」に ACS URL を入力します。
- Google Workspace では、管理コンソールの「アプリ」から「ウェブアプリとモバイルアプリ」を開き、カスタム SAML アプリを追加して、ACS URL とエンティティ ID を入力します。
あわせて、アサーションに含める属性を設定します。WordPress 側で使うのは、少なくともメールアドレスです。表示名や姓・名、グループを渡すこともできます。NameID の形式をメールアドレスにしておくと、突き合わせが分かりやすくなります。
最後に、このアプリケーションを使えるユーザーやグループを割り当てます。割り当てていないアカウントでテストして「アクセス権がない」と表示されるのは、IdP 側の割り当て漏れです。
3. IdP情報をWordPressに登録する
IdP 側に表示される IdP のエンティティ ID、SSO URL、署名証明書（またはそれらをまとめた IdP メタデータ）を、プラグインの設定画面に入力します。属性の対応付け（どの属性をユーザー名・メールアドレスとして扱うか）も、ここで設定します。
4. 一般ユーザーでテストする
管理者でログインしたままのブラウザとは別に、シークレットウィンドウなどでテストします。管理者のセッションを残しておけば、設定を誤っても元に戻せます。確認するのは次の点です。
- IdP に転送され、認証後に WordPress へ戻ってログインできるか
- 既存ユーザーと正しく対応付けられているか（同じ人のアカウントが二重に作られていないか）
- 自動作成されたユーザーの権限が想定どおりか
- ログアウトの挙動（WordPress だけ抜けるのか、IdP からも抜けるのか）
5. 運用に切り替える
テストが済んだら、SSO 以外のログイン方法をどうするか決めます。ID とパスワードでのログインを残すと SSO の利点が薄れますが、すべて閉じると緊急時に入れなくなります。プラグインの設定で、ローカルログインを特定の管理者に限るなどの方法を検討してください。
また、SSO を導入しても、プラグインの設定によっては XML-RPC やアプリケーションパスワード（WordPress 5.6 以降のコア機能）が SSO を通らない入口として残ります。どの経路が使えるのかをテスト時に確かめ、使っていないなら、アプリケーションパスワードは次のフィルターで無効にできます。
add_filter( 'wp_is_application_passwords_available', '__return_false' );ログインできないときの確認ポイント
SAML のエラーは画面に詳しい理由が出ないことが多いので、プラグインのデバッグ機能や PHP のエラーログを有効にして確認します。原因として多いのは次のものです。
- ACS URL の不一致:
httpとhttps、末尾のスラッシュの有無、www の有無が1文字でも違うと拒否される。リバースプロキシの裏で WordPress が自分をhttpだと認識していると、送信する URL がずれることがある - 時刻のずれ: アサーションには有効期間が含まれるため、サーバーの時刻がずれていると「期限切れ」や「まだ有効でない」と判定される。
timedatectlなどで NTP の同期状態を確認する - 証明書の期限切れ・差し替え: IdP 側で署名証明書を更新したら、WordPress 側の証明書も入れ替える。期限を社内のカレンダーなどで管理しておくと安心
- 属性名の不一致: IdP が送る属性名と、プラグインで指定した属性名が違うと、メールアドレスが空になりユーザーを特定できない
- キャッシュ: ページキャッシュや CDN がログインページや ACS URL をキャッシュしていると、正しく処理されない。認証関連の URL はキャッシュ対象から外す
まとめ
- SAML 連携では、IdP（認証する側）と SP（WordPress）の間で、エンティティ ID・ACS URL・SSO URL・証明書をやり取りする
- コアに SAML 機能はないため、更新が続いているプラグインを選び、ステージングで設定する
- 既存ユーザーとの対応付け、自動作成と権限、緊急用ログインの扱いを事前に決める
- テストは管理者のセッションを残したまま、別のブラウザで行う
- つまずきやすいのは ACS URL の不一致、時刻のずれ、証明書の期限、属性名、キャッシュ
- SSO 導入後も、XML-RPC とアプリケーションパスワードの扱いを見直す