複数の接続オプションから選択

Lock V11 で複数のログインオプションに対応するために、異なる接続タイプを選択する方法。

Auth0 を使うと、ユーザーに複数の認証方法を提供できます。これは、1 つのアプリを複数の組織で利用する SaaS やマルチテナントのアプリでは重要です。組織ごとに、LDAP、Active Directory、Google Workspace、またはユーザー名/パスワード ストアなど、異なるシステムを使っていることがあるためです。

Auth0 では、異なる接続 (認証方法) を特定のアプリケーションに関連付けることも、直接テナントに関連付けることもできます (ドメイン接続 として) 。ユーザーがログインする際には、使用する接続としてそのうち 1 つを選ぶ必要があります。

複数の選択肢の中から適切な IDプロバイダー を選択することを、“ホームレルムディスカバリー” と呼びます。

データベース接続を最大 1 つと、0 個以上のソーシャル接続のみを使用する場合、選択プロセスはシンプルです。ユーザーはいずれかを行います。

• ソーシャルアイデンティティプロバイダーのボタンを 1 つクリックする (例: “Google でログイン”)
• メールアドレスとパスワードを入力する (つまり、“データベース接続を使います” という意味です) 。

ただし、アプリケーションまたはテナントで他の接続タイプ (エンタープライズ接続や複数のデータベースなど) が有効になっている場合は、選択プロセスがもう少し複雑になることがあります。複数のデータベース接続が有効な場合、ユーザーが特定のデータベース接続を使いたいことを、どのように示せばよいのでしょうか。ユーザーが シングルサインオン (SSO) を使ってログインするために、エンタープライズ接続を使いたい場合はどうでしょうか。

カスタムログイン UI を実装すると、認証フローを完全に制御できます。コンテキスト (指定されたメールアドレスなど) に基づいて接続を選ぶことも、ユーザーに確認して選ばせることもでき、その後、auth0.js の ログインメソッド の 1 つに connection パラメーターを渡せます。

Lock と複数の接続

Lock には、アイデンティティプロバイダーを選択するための機能が組み込まれています。ソーシャル接続については、特定のアプリケーションで有効になっているすべてのロゴが表示されます。また、データベース接続または Active Directory 接続が有効になっている場合は、ユーザー名 / メールアドレスとパスワードの入力欄も表示されます。

ログインボタンが表示されるのは、その接続のみがアプリケーションで有効になっている場合に限られます (Classic Universal Login エクスペリエンスの場合) 。それ以外の場合は、カスタム UI を使用するか、有効になっている各ソーシャル接続およびエンタープライズ接続ごとにボタンを表示できる New Universal Login を使用する必要があります。

エンタープライズ接続でメールドメインを使用する

Lock の追加機能の 1 つとして、認証リクエストの振り分けにメールドメインを使用できます。Auth0 のエンタープライズ接続は domains にマッピングできます。たとえば、ADFS または SAML-P のアイデンティティプロバイダーを設定する場合です。

接続にドメインがマッピングされている場合、ユーザーがそのドメインにマッピングされたメールアドレスを入力すると、パスワード入力欄は自動的に無効になります。

上の例では、ドメイン auth0.com がエンタープライズ接続にマッピングされています。

また、1 つの接続に複数のドメインを関連付けることもできます。

複数のデータベース接続から選択する

アプリケーションで複数のデータベース接続が有効になっている場合、Lock はどの接続を使用するかを把握する必要があります。connectionResolver オプションを指定すると、ユーザー入力とコンテキストに基づいて使用する接続を決定する関数を渡せます。この例では、メールドメインが “auth0.com” の場合、別のデータベース接続が使用されます。

var options = {
  connectionResolver: function (username, context, cb) {
    var domain = username.indexOf('@') !== -1 && username.split('@')[1];
    if (domain && domain ==='auth0.com') {
      // ユーザー名が [e-mail] の場合、使用される接続は `auth0-users` 接続になります。
      cb({ type: 'database', name: 'auth0-users' });
    } else {
      // デフォルトの方法で接続を特定します
      cb(null);
    }
  }
}

defaultDatabaseConnection オプションを使用すると、デフォルトで使用するデータベース接続を指定できます。

利用可能な接続をプログラムから絞り込む

Lock の allowedConnections option を使うと、利用可能な接続のうち、ユーザーに選択肢として表示するものを指定できます。

これにより、追加の入力やコンテキストに応じて、ユーザー体験を調整できます (例：“学生としてログインするにはここをクリック、教職員としてログインするにはこちらをクリック”) 。

ユースケースによっては、インスタンス化時に指定するのが適切でない場合、lock.show() メソッドに allowedConnections オプションを渡すこともできます。詳細については、show メソッドの API ドキュメント を参照してください。

アプリケーションからレルム情報を送信する

認証を要求するアプリケーションが、ユーザーが使用する想定のレルムをあらかじめ把握できる場合があります。たとえば、マルチテナントのアプリケーションでは、https://{customer}.yoursite.com や https://www.yoursite.com/{customer} のような形式の URL を使用することがあります。ユーザーがその vanity URL からアプリケーションにアクセスした場合は、その tenant の値を取得して、authorize リクエストの login_hint として渡せます。

https://{yourDomain}/authorize?client_id=[...]&login_hint={customer}

login_hint は、ユーザーがログインに何を使う可能性があるかを示すための、認可サーバー (Auth0) へのヒントです。この場合は、ユーザーがアクセスした URL に基づいて、“customer” をレルムとして扱います。

デフォルトのホスト型ログインページのコードでは、これを使って Lock のメールアドレス欄を事前入力しますが、実際のメールアドレスではなくレルムが指定されている場合は、使用するデフォルトのデータベース接続を変更するようにコードを修正できます。

// デフォルトのホスト型ログインページテンプレートより
var config = JSON.parse(decodeURIComponent(escape(window.atob('@@config@@'))));
[...]

var loginHint = config.extraParams.login_hint;
var realmHint;

// ログインヒントがメールアドレスでない場合、レルムヒントとして扱う
if (loginHint && loginHint.indexOf('@') < 0) {
  realmHint = loginHint;
  loginHint = null;
}

// レルムを実際のデータベースにマップする
var defaultDatabaseConnection;
if (realmHint === 'acme') {
  defaultDatabaseConnection = 'acme-users';
} else if (realmHint === 'auth0') {
  defaultDatabaseConnection = 'auth0-DB';
}
    
// Lockの設定時に、上記で取得した値を渡す
var lock = new Auth0Lock(config.clientID, config.auth0Domain, {
  [...] // その他のオプション
  prefill: loginHint ? { email: loginHint, username: loginHint } : null,
  defaultDatabaseConnection: defaultDatabaseConnection
}

もちろん、上記のコードは単なるサンプルです。このロジックは、ソーシャル接続を除外するように拡張したり、メールアドレスが login_hint として指定されている場合でも使用するデフォルトの接続を設定したりできます。

この例で “customer” をレルムとしてマッピングしているのは、あくまで任意の設計上の判断です。ただし一般的には、アプリケーションを Auth0 内で使われる実際の “connection” の概念から切り離し、代わりにより抽象的な “realm” の概念を使うのが望ましいです。必要に応じて変更しやすいホスト型のログインページ内で、レルムから接続へのマッピングを行うこともできます。