[Auth0] 1つのApplicationから2つの異なるDatabaseに繋いで認証させる方法
今回は
「2つの異なる組織に所属しているユーザーに、共通のログインページを提供したい」
という要求を、Auth0で実現できるのか検証していきます。これはシステム要件としては
「1つのApplicationに2つの異なるUser DatabaseをConnectionに設定しているときに、Database1かDatabase2のいずれかにユーザーが存在するときにログインさせることができるか?」
と言うことになります。
少しでもAuth0を触ったことがあれ人であれば、「Connectionsで2つのDatabaseを有効化すれば良いのでは?」と思うかも知れません。
しかし、現時点(2024/04/06)のAuth0の仕様では、1つのApplicationからはデフォルトで片方のDatabaseでしか認証できず、もう片方のDatabaseで認証することはできません。
Auth0 will default to just one user/password database connection, so in your case its current default is Database 1.
試してみると、2つ目のDatabaseに登録してあるユーザーではログインが失敗します。上記のコミュニティノートが言ってるように、1つ目のDatabaseにしか繋がってないようです。
※クリックするとGIFが再生されます。
では、冒頭の「2つの異なる組織に所属しているユーザーに、共通のログインページを提供したい」場合どうすればいいのでしょう。
この要求を満たす方法を2つ紹介します。
1. Organizationsを使う方法
ユニバーサルログインを使う場合はOrganizationsを使うのが自然だと思います。
詳細は省きますが、こちらのように設定します。
2つOrganizationを作成します。
1つ目のOrganizationは1つ目のDatabaseを、2つめのOrganizationは2つめのDatabaseを対応させます。
対象のApplicationの設定でOrganization → Prompt for Organization
を有効化します。
以上のように設定すると、2つの異なる組織のユーザーに共通のログインページを提供し、ログインさせることが可能となります。
こちらは、Database2に登録してあるユーザーがログインしている様子です。
※クリックするとGIFが再生されます。
Prompt for Organization
は、ログイン時にユーザーに自身の組織名を入力する方式です。
この、わざわざ自身の組織名を入力させるステップは、実際の案件では要件を満たさない場合があると思います。
また、Organizationsは契約しているSubscription次第では使えません。
2. クライアントアプリケーションを改修する方法
この方法は、フロントエンドでログイン画面を自由に改修するので、Organizationsに比べて柔軟にログインフローをカスタマイズできます。
以下はAuth0 Lockによるカスタムログインページ実装の一部です。
もちろん、Auth0 Management APIを呼び出しつつフルスクラッチで実装してもOKです。
var lock = new Auth0Lock(config.clientID, config.auth0Domain, { // ...もろもろの設定値 allowedConnections: ['double-db-1', 'double-db-2'], }); // ボタンをクリックしたときの挙動を定義 function selectConnection(connectionName) { lock.show({ allowedConnections: [connectionName], }); } // ページが読み込まれたらボタンにイベントリスナーを追加 window.addEventListener('load', function () { document.getElementById('login-db1').onclick = function () { selectConnection('double-db-1'); }; document.getElementById('login-db2').onclick = function () { selectConnection('double-db-2'); }; });
以上のように実装すると、ログインの前にどちらのDatabaseで認証するかユーザーが選択して先に進むことが出来ます。
※クリックするとGIFが再生されます。
ただ、この方法も、クライアントアプリケーションが存在しない場合は実現できません。例えば、他のSaaS製品と連携している場合は、ログイン制御はSaaSアプリケーションに依存していると思います。
つまり認証前に何らかの処理を実行し、柔軟にカスタマイズしたいのであれば、クライアントアプリケーションが必要になります。
最後に
ところで、現在(2024/04/06)のAuth0には認証前(Pre Login)のカスタムフックはありません。
Unfortunately we only have post-user registration hook and pre-user registration one.
もし認証前のカスタムフック機能がリリースされたら、冒頭の要求を、クライアントアプリケーション無しで満たすことができるようになると思います。
以上です。