WordPressのSSO（シングルサインオン）設定方法｜SAML・OpenID Connect・Googleログイン

SSO（シングルサインオン）を設定すると、社員や会員が、すでに持っているアカウント（Google Workspace、Microsoft Entra ID、Okta など）でWordPressにログインできるようになります。WordPress用のパスワードを別に管理する必要がなくなり、退職者のアカウント停止なども、ID管理側（IdP）の操作だけで済むようになります。

WordPressは、SSOでは「ログインさせてもらう側」（SAMLではSP、OpenID ConnectではRP）になります。ログインの処理はIdP側で行い、WordPressは結果を受け取ってユーザーをログイン状態にします。この受け取りの部分はプラグインで実装するのが一般的です。

SSOの方式と選び方

選び方の目安は次のとおりです。

• Googleアカウントだけで足りるなら、Googleログイン用のプラグインがいちばん手軽です
• IdPがOpenID Connectにも対応していれば、設定項目が少ないOpenID Connectが扱いやすい選択です
• 社内の規程やIdP側の都合でSAMLを使う必要がある場合は、SAML 2.0のプラグインを使います

方式ごとのプラグイン

いずれも wordpress.org で配布されているプラグインです（2026年10月時点）。

なお、「WP OAuth Server」（スラッグ oauth2-provider）は、WordPressをIdP（OAuth 2.0の認可サーバー）にして、ほかのアプリをWordPressのアカウントでログインさせるためのプラグインです。外部のIdPでWordPressにログインするSSOとは向きが逆なので、目的に合わせて選んでください。

Googleアカウントでログインさせる場合

Google Cloud でOAuthクライアントを作り、承認済みのリダイレクトURIに https://example.com/wp-login.php を登録して、クライアントIDとシークレットを Log in with Google に設定します。Google Workspaceの組織内だけで使う場合は、Google側の同意画面の対象を「内部」にし、プラグイン側でも新規登録できるドメインを自社ドメインに限定します。手順は次の記事で詳しく説明しています。

• WordPressにGoogleログインを追加する方法

OpenID Connectで連携する場合

OpenID Connect Generic Client では、IdP側にアプリ（クライアント）を登録し、発行されたクライアントID・シークレットと、IdPの認可・トークン・ユーザー情報のエンドポイントのURLをプラグインの設定画面に入力します。

IdP側に登録するリダイレクトURIは、既定では次の形です。

https://example.com/wp-admin/admin-ajax.php?action=openid-connect-authorize

IdPがクエリ文字列つきのリダイレクトURIを受け付けない場合は、設定画面の「Alternate Redirect URI」にチェックを入れると、https://example.com/openid-connect-authorize を使えます。具体的な設定は次の記事を参照してください。

• WordPressでOpenID ConnectのSSOを設定する方法

SAMLで連携する場合（WP SAML Auth と Microsoft Entra ID の例）

ここでは、WP SAML Auth を使って Microsoft Entra ID（旧 Azure AD）とSAMLで連携する例を説明します。WP SAML Auth は、「設定」→「WP SAML Auth」の画面でも主な項目を設定できますが、すべての項目を扱えるのはフィルターでの設定です。フィルターで設定すると、管理画面の設定ページは使えなくなります。

ステップ1：プラグインをインストールする

wp plugin install wp-saml-auth --activate

ステップ2：Entra ID 側にアプリを登録する

Microsoft Entra 管理センターで次の操作をします（画面の名称は2026年10月時点の英語表示）。

1. 「Entra ID」→「Enterprise apps」で「New application」を選び、「Create your own application」でギャラリーにないアプリとして作成する
2. 作成したアプリの「Single sign-on」で「SAML」を選ぶ
3. 「Basic SAML Configuration」に、下の表の2つの値を入力する
4. 「SAML Certificates」から「Certificate (Base64)」をダウンロードし、「Set up」欄に表示されるテナントIDとログインURLを控える
5. 「Users and groups」で、WordPressにログインさせるユーザーやグループを割り当てる

WP SAML Auth は、IdPからの応答を wp-login.php で受け取ります。WordPressをサブディレクトリに置いている場合は、実際のログインページのURLにします。

ステップ3：wp-config.php にテナントIDと証明書の場所を書く

ダウンロードした証明書ファイルは、公開ディレクトリ（ドキュメントルート）の外に置きます。

<?php
// wp-config.php の「編集が必要なのはここまでです」より上に追加
define( 'SAML_TENANT_ID', '00000000-0000-0000-0000-000000000000' );   // Entra ID のテナントID
define( 'SAML_IDP_CERT_FILE', '/home/example/saml/entra-id.cer' );    // 公開ディレクトリの外に置く

SAML_TENANT_ID と SAML_IDP_CERT_FILE は、この記事のコードで使うために決めた名前です。

ステップ4：WP SAML Auth の設定を mu-plugin に書く

設定のフィルターは、プラグインが初期化される前に読み込まれる場所に書きます。テーマに依存しないよう、wp-content/mu-plugins/wp-saml-auth-config.php として置きます。

<?php
/**
 * Plugin Name: WP SAML Auth 設定（Microsoft Entra ID）
 * Description: wp-content/mu-plugins/ に置く。設定はこのファイルが優先され、管理画面の設定ページは使えなくなる。
 */

add_filter( 'wp_saml_auth_option', function ( $value, $option_name ) {
    // wp-config.php で定義する: SAML_TENANT_ID（テナントID）、SAML_IDP_CERT_FILE（証明書ファイルのパス）
    if ( ! defined( 'SAML_TENANT_ID' ) || ! defined( 'SAML_IDP_CERT_FILE' ) ) {
        return $value;
    }

    $idp_url = 'https://login.microsoftonline.com/' . SAML_TENANT_ID . '/saml2';
    $claims  = 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/';

    $options = [
        'connection_type'        => 'internal',
        'internal_config'        => [
            'strict'  => true,
            'debug'   => defined( 'WP_DEBUG' ) && WP_DEBUG,
            'baseurl' => home_url(),
            'sp'      => [
                'entityId'                 => 'urn:' . wp_parse_url( home_url(), PHP_URL_HOST ),
                'assertionConsumerService' => [
                    'url'     => wp_login_url(),
                    'binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
                ],
            ],
            'idp'     => [
                'entityId'            => 'https://sts.windows.net/' . SAML_TENANT_ID . '/',
                'singleSignOnService' => [
                    'url'     => $idp_url,
                    'binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
                ],
                'singleLogoutService' => [
                    'url'     => $idp_url,
                    'binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
                ],
                'x509cert'            => file_get_contents( SAML_IDP_CERT_FILE ),
            ],
        ],
        'auto_provision'         => true,          // 未登録ユーザーを自動作成する
        'permit_wp_login'        => true,          // ユーザー名とパスワードでのログインも残す
        'get_user_by'            => 'email',       // 既存ユーザーをメールアドレスで照合
        'user_login_attribute'   => $claims . 'name',
        'user_email_attribute'   => $claims . 'emailaddress',
        'display_name_attribute' => $claims . 'name',
        'first_name_attribute'   => $claims . 'givenname',
        'last_name_attribute'    => $claims . 'surname',
        'default_role'           => 'subscriber',  // 自動作成するユーザーの権限
    ];

    return array_key_exists( $option_name, $options ) ? $options[ $option_name ] : $value;
}, 10, 2 );

主な設定の意味は次のとおりです。

属性名に使っている http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress などは、Entra ID が既定で送るクレームの名前です。Entra ID 側の「Attributes & Claims」でクレームを変えた場合や、ほかのIdPを使う場合は、IdPが実際に送る属性名に合わせてください。属性名が合っていないと、ログイン時に「"…" attribute is expected, but missing」というエラーになります。

ステップ5：動作を確認する

1. ブラウザのプライベートウィンドウで https://example.com/wp-login.php を開き、SAMLでのログイン用のボタンが表示されることを確認する
2. ボタンからEntra IDのログイン画面に移り、割り当てたユーザーでログインして、WordPressに戻ってログイン状態になることを確認する
3. 自動作成されたユーザーの権限が default_role のとおりかを、「ユーザー」一覧で確認する

すべて確認できたら、必要に応じて permit_wp_login を false にし、SAML以外のログインを止めます。その場合も、非常時に設定を戻せるよう、サーバーにSSHやFTPで入れる手段を確保しておきます。

SAMLの受け取り処理は自作しない

SAMLの受け取りを init フックなどで自作し、$_POST['SAMLResponse'] を受け取ってユーザーをログインさせるコードを見かけることがあります。しかし、SAML応答は、署名の検証、宛先（Audience・Destination）の確認、有効期限の確認、再送攻撃の防止などを正しく行わないと、第三者が作った応答でだれにでもなりすませてしまいます。これらは、保守されているライブラリやプラグインに任せてください。WP SAML Auth も、同梱ライブラリやユーザー照合の不具合を修正する更新を出しているので、プラグインは最新に保ちます。

注意点

• 緊急用のローカル管理者を残す：IdPの障害や証明書の期限切れでSSOが使えなくなっても入れるよう、SSOに依存しない管理者アカウントを1つ残し、強いパスワードと2段階認証を設定しておきます
• 自動作成の権限は最小に：default_role は subscriber など最小の権限にし、編集者や管理者の権限はWordPress側で個別に付けます
• 証明書の更新：IdPの署名証明書には有効期限があります。IdP側で証明書を更新したら、WordPress側の証明書ファイルも差し替えます
• サーバーの時刻：SAMLアサーションには有効期間があるため、サーバーの時刻が大きくずれていると検証に失敗します。NTPなどで時刻を合わせておきます
• 秘密情報の置き場所：OpenID Connectのクライアントシークレットや証明書ファイルは、テーマのファイルや公開ディレクトリに置かず、wp-config.php の定数やドキュメントルートの外に置きます

まとめ

• WordPressはSSOでSP（RP）になり、ログインの処理はIdPに任せる。受け取りはプラグインで行う
• Googleだけなら Log in with Google、OpenID Connect対応のIdPなら OpenID Connect Generic Client、SAMLが必要なら WP SAML Auth などを使う
• WP SAML Auth は wp_saml_auth_option フィルターで全項目を設定でき、IdPのACSには wp-login.php を登録する
• 動作確認が済むまでパスワードログインを残し、緊急用のローカル管理者、自動作成時の最小権限、証明書の更新を運用に組み込む

関連記事

• WordPressにGoogleログインを追加する方法
• WordPressでOpenID ConnectのSSOを設定する方法