WordPress アプリケーションへ認証機能の追加
より良いユーザー体験のために、このチュートリアルに従う代わりに、公式の WordPress プラグイン を使用することをお勧めします。
このチュートリアルでは、Logto を Wordpress ウェブサイトに統合する方法を紹介します。
前提条件
- Logto Cloud アカウントまたは セルフホスト Logto。
- 作成された Logto の従来のアプリケーション。
- WordPress プロジェクト：公式の Wordpress インストールガイド に従って、Wordpress ウェブサイトをセットアップしてから進めてください。
統合
プラグインのインストール
OpenID Connect Generic プラグインを使用して、OIDC プロトコルを介して Logto を Wordpress ウェブサイトに統合します。
- WordPress サイトにログインします。
- 「プラグイン」に移動し、「新規追加」をクリックします。
- 「OpenID Connect Generic」を検索し、daggerhart によるプラグインをインストールします。
- プラグインを有効化します。
リダイレクト URI の設定
まず、リダイレクト URI を設定しましょう。プラグイン設定で見つけることができ、「Notes」セクションまでスクロールして「Redirect URI」値をコピーします。
Logto コンソールのアプリケーション詳細ページに切り替えます。リダイレクト URI を追加し、「変更を保存」をクリックします。
プラグインの設定
必要な設定詳細については、以下の表を参照してください：
| プラグインフィールド | 説明 |
|---|---|
| Client ID | Logto アプリケーションのアプリ ID |
| Client Secret | Logto アプリケーションのアプリシークレット |
| OpenID Scope | email profile openid offline_access を入力 |
| Login Endpoint URL | Logto アプリケーションの認可エンドポイント URL、https://[tenant-id].logto.app/oidc/auth で、Logto アプリケーションページで「エンドポイント詳細を表示」をクリックして URL を取得できます。 |
| Userinfo Endpoint URL | Logto アプリケーションのユーザー情報エンドポイント URL、https://[tenant-id].logto.app/oidc/me。 |
| Token Validation Endpoint URL | Logto アプリケーションのトークン検証エンドポイント URL、https://[tenant-id].logto.app/oidc/token。 |
| End Session Endpoint URL | Logto アプリケーションのセッション終了エンドポイント URL、https://[tenant-id].logto.app/oidc/session/end。 |
| Identity Key | ユーザーのアイデンティティを含む ID トークン内の一意のキー、設定に応じて email または sub にできます。 |
| Nickname Key | ユーザーのニックネームを含む ID トークン内のキー、sub に設定して後で変更できます。 |
チェックポイント: アプリケーションのテスト
これで、アプリケーションをテストできます：
- WordPress サイトからログアウトします。
- WordPress ログインページにアクセスし、「Logto でサインイン」ボタンをクリックします。
- Logto サインインページにリダイレクトされます。
- Logto アカウントでサインインします。
- WordPress サイトに戻り、自動的にログインされます。
ロールのマッピング
WordPress には、サイト上でユーザーが実行できるアクション（機能）を定義する組み込みのユーザーロール管理システムがあります。デフォルトのユーザーロールには、管理者、編集者、著者、寄稿者、購読者が含まれ、それぞれに独自の機能セットがあります。
Logto は、認可 (Authorization) モデルとしてロールベースのアクセス制御 (RBAC) を採用し、「スコープ」を権限の最小単位として利用します。これらのスコープは、認証されたユーザーがアプリケーション内で実行できる特定のアクションを定義します。しかし、WordPress は、さまざまな機能をまとめた事前定義された「ロール」に依存してユーザー権限を管理する異なる原則で動作します。
この基本的な違いを考慮して、WordPress で定義されたロールに対応する特別なロールを Logto 内に作成することをお勧めします。これらのロールにはスコープがないかもしれませんが、ユーザーを WordPress ロールにマッピングするための参照として使用されます。
前提条件
- WordPress のロールに対応する Logto 内のロールを設定します。例えば、WordPress に 'editor' ロールがある場合、Logto に 'group:editors' ロールを作成します。
ロールマッピングの実装
ロールマッピングを実装するために、WordPress テーマの functions.php ファイルにカスタムコードを追加します。これは、ユーザーがログインしたときにトリガーされる wp_login アクションフックを使用します。設定方法のステップバイステップガイドは以下の通りです：
ステップ 1: テーマの functions.php にアクセス
テーマの functions.php ファイルを開きます。このファイルには、WordPress サイトの機能を拡張するカスタム PHP 関数を追加できます。WordPress 管理パネルから「外観 > テーマエディター」に移動し、右側のファイルリストから functions.php を選択してアクセスできます。または、ソースコードで WordPress テーマディレクトリに移動し、functions.php ファイルを見つけます。
ステップ 2: ロールマッピング関数を書く
以下は、functions.php に追加する関数の簡単な例です。この関数はユーザーのログイン時にトリガーされ、Logto から取得したユーザーの roles クレームに基づいてロールを割り当てます。
function logto_handler($user_login, $user = null) {
if (!$user) {
$user = get_user_by('login', $user_login);
}
$oidc_claims = get_user_meta($user->ID, 'openid-connect-generic-last-user-claim', true);
if (in_array('group:editors', $oidc_claims['roles'])) {
$user->set_role('editor');
} else {
$user->set_role('subscriber');
}
}
add_action('wp_login', 'logto_handler', 10, 2);
ステップ 3: コードの理解とカスタマイズ
-
logto_handler関数：この関数は、$user_login（ユーザー名）と$user（ユーザーオブジェクト）の 2 つのパラメーターを受け取ります。ユーザーメタにopenid-connect-generic-last-user-claimとして保存された Logto からのロールを取得し、このロールを対応する WordPress ロールにマッピングしてユーザーに割り当てます。 -
add_action：この行は、logto_handler関数をwp_loginアクションにフックします。これは、ユーザーがログインした後にトリガーされます。10は優先度（デフォルト）で、2は関数が受け取る引数の数を示します。
上記の例では、Logto で group:editors というロール名を持つユーザーに 'editor' ロールを割り当てます。しかし、実際のシナリオでは、より多くの種類のロールマッピングを実装する必要があるでしょう。
WordPress のロールとその機能のリストは こちら で確認できます。
ステップ 4: 設定のテスト
次に、Logto で group:editors ロールを持つユーザーでログインして、ロールマッピング関数をテストします。ログイン後、WordPress でユーザーのロールを確認し、マッピングが正しく機能していることを確認します。