ユーザーがどのように登録されるかを早い段階で決めておくことは重要です。ここでの判断は、今後必要になる多くの意思決定に影響します。ユーザーをシステムに追加する方法には一般的ないくつかのパターンがあり、ワークフロー設計を検討する際に留意すべき点もあります。
ベストプラクティス Auth0 は多数のワークフローをサポートしていますが、サインアップには Auth0 の Universal Login を使用する Web ベースのワークフローが、最適な機能と最高水準のセキュリティを提供できるため、業界標準および Auth0 のベストプラクティスとされています。 Auth0 は、さまざまな IDプロバイダー を介したユーザーのサインアップをサポートしています。サインアップ時には、Auth0 が ユーザープロファイル をプロビジョニングし、ユーザーのアカウント情報を格納します。機能やワークフローを検討する際には、次の点を考慮してください。
ユーザーは自社のドメインに追加されますか。それとも、そのユーザーの組織のドメインに所属または残りますか。
ユーザーが自分のドメインにとどまる場合、そのユーザーは 1 つの組織のみに所属しますか。それとも複数の組織に所属できますか。
組織自体をシステム内でどのようにプロビジョニングしますか。
Auth0 を ID ストアとして使用すべきですか。
Auth0 で独自の (レガシー) ID ストアを使用できますか。
ID ストアから Auth0 にユーザーアイデンティティをどのように移行しますか。
ユーザーは自分の組織の IDプロバイダー
ユーザーを招待制にできますか。それともセルフ登録を許可できますか。
他の企業にサービスを提供する際に、まず決めるべきことの 1 つは、ユーザーがどのドメインに属するかです。その答えに応じて、それらのユーザーをプロビジョニングするためにいくつかの異なるアプローチを取ることができます。詳細については、組織ユーザーのプロビジョニング を参照してください。組織をシステム内でどのように表現するかが決まったら、次に組織自体をどのようにプロビジョニングするかを検討します。詳細については、組織のプロビジョニング を参照してください。
Auth0 には、ユーザー資格情報を安全に保存できる、すぐに利用可能な ID ストレージが用意されています。詳細については、セルフサインアップ を参照してください。すでにレガシー ID ストアがあり、その管理を Auth0 に任せたい場合は、ユーザー移行 機能によって、そのためのさまざまな選択肢が提供されます。
一方で、レガシー ID ストアを維持しなければならない場合、たとえばまだ移行の準備ができていないアプリケーションがある、または移行できないアプリケーションがある場合は、ID ストアプロキシ 機能を使用できます。また、顧客が「独自の ID を持ち込む」ことを許可するのも魅力的な選択肢です。多くの顧客は当初はそうしていませんが、ソーシャルサインアップ 機能を使ってこれを提供できます。
組織をプロビジョニングする際に必要な作業は、組織をシステム内でどのように表現しているかによって異なります。少し立ち止まって、それらの組織のユーザーがアプリケーションをどのように利用するかを検討する必要があるため、時間がかかることがあります。IAM システムで組織をどのように構成すべきかを判断するには、複数組織アーキテクチャ を参照してください。
組織をプロビジョニングする際は、次の点を考慮する必要があります。
自社のアプリケーション設定やデータベースに組織を追加する必要があります
Auth0 の設定を変更する必要があります。これには、次の一部またはすべての作業が含まれます。
まれなケース: その組織専用のテナントを作成する
Auth0 テナントに新しい組織を作成する
その組織用に新しいデータベース接続を追加する (組織ごとにユーザーを分離している場合)
既存の共有データベース接続をその組織で有効にする (ユーザーを共有している場合)
その組織用のエンタープライズ接続を追加し、組織で有効にする
これには、その組織と連携して既存の設定を更新するか、その組織がレガシー組織でない場合は Auth0 テナント向けの設定を追加する作業が含まれます。
その組織の管理者をプロビジョニングする
ミスを防ぐために、新しい組織をより簡単にプロビジョニングできるよう、組織管理者ポータル を作成するとよいでしょう。
組織向けにセルフサインアップポータルを作成することもできます。これにより、顧客自身が組織を作成できるようになります。これは 組織管理者ポータル の一部にすることもできます。
組織管理者ポータルは、管理者が組織を作成、変更、削除できるポータルです。こうした管理者は、自社の従業員である場合もあれば、顧客側の管理者である場合もあります。実施が必要な作業は、自社システムと Auth0 テナントの両方にまたがって複数あります。このポータルは、自社のデータストアや設定にアクセスする必要があるため、自社システム内に用意することになる可能性が高いでしょう。一方で、Auth0 は Auth0 Management API を提供しているため、自社システムで変更を行うのと同時に、Auth0 テナントにも変更を反映できます。
新しい組織を作成する方法には、主に 2 つのアプローチがあります。どちらを選ぶかは、新しい組織のデプロイにどれだけ時間をかけられるかによって大きく変わります。
Auth0 テナントへのライブ更新 : 新しい組織をリアルタイムで作成できるようにしたい場合は、Auth0 の Management API
ライブ更新には、考慮すべき点がいくつかあります。問題を避けるために、直列で実行しなければならない操作があります。たとえば、接続でクライアントを有効にする操作や、アプリケーションにコールバック URL を追加する操作です。Management API で、一覧全体を取得し、新しい値を追加したうえで一覧全体を再送信しなければならない操作は、並列実行した 2 つの処理のどちらかが値を上書きしてしまうのを防ぐため、直列で実行する必要があります。
リポジトリを変更して再デプロイする : CI/CD パイプライン の一部として Deploy CLI (またはカスタム CLI) を利用している場合は、変更をリポジトリに直接プッシュし、その後で新しいデプロイを開始する方法のほうが適していることもあります。こちらは多少時間がかかる可能性がありますが、バージョン履歴を管理しやすく、以前のバージョンを再デプロイして変更をロールバックできるという利点があります。組織に必要な項目専用のリポジトリを別に用意しておけば、他の共通コンポーネントを再デプロイする必要がなくなり、誤りを招くリスクも減らせるでしょう。
Auth0 は、ユーザープロファイル をホストするだけでなく、お客様の既存のレガシー ID ストアをプロキシ し、さらに Auth0 がホストする安全な代替ストアを提供することもできます。これらはいずれも、Auth0 のデータベース接続 を使用してサポートされます。レガシー ID ストアの置き換え先として Auth0 を使用する場合は、ユーザー移行 により、bulk migration で一括移行することも、automatic migration で段階的に移行することもできます。
ベストプラクティス ユーザー移行では、2 段階のアプローチを採用するケースがよくあります。まず Automatic Migration を使用してできるだけ多くのユーザーを移行し、その後、残ったユーザーに対して Bulk Migration を使用します。詳しくは、ユーザー移行シナリオ を参照してください。 Automatic Migration が推奨されます。ユーザーを 1 人ずつ移行でき、ほぼすべてのケースで既存のパスワードも維持できるためです。Bulk Migration については、ごく単純なケースを除き、User Import/Export extension ではなく Management API を使用することを推奨します。Management API のほうが、より高い柔軟性と制御性を備えているためです。
Bulk Migration では通常、レガシー ID ストア内のパスワードがサポート対象のアルゴリズムのいずれかでハッシュ化されて保存されていない限り、ユーザーは移行完了後に一度パスワードをリセットする必要があります 。この場合は、アルゴリズムと使用されているソルトラウンド数によって、bulk migration を使用しながら、処理の一環としてユーザーパスワードを保持できる 可能性があります。詳しくは、Bulk Import Database Schema Examples を参照してください。
ハッシュ化されたパスワードをインポートするには、移行元の ID ストアで次のいずれかのアルゴリズムが標準的な実装で使われている必要があります: argon2, bcrypt, hmac, ldap, md4, md5, sha1, sha256, sha512, pbkdf2, and scrypt.
Auth0 の データベース接続 タイプは、既存の (レガシー) ID ストアをプロキシするように設定することもできます。独自のレガシー ストアで管理しているユーザー ID を維持する必要がある場合、たとえば Auth0 に移行できないものの、引き続きそれらの ID にアクセスする必要がある業務上重要なアプリケーションが 1 つ以上ある場合でも、Auth0 と簡単に統合できます。詳細については、データベースを使用してユーザーを認証する を参照してください。
組織は、ビジネス上の顧客またはパートナーのいずれか 1 つに直接対応するようにします。連携している各顧客またはパートナーには、ログインするユーザーが存在します。こうしたエンドユーザーを「組織ユーザー」と呼びます。組織ユーザーの保存方法には、2 つの異なるアプローチがあります。
組織ごとに分離する : すべてのユーザーは、必ず 1 つの組織のみに属します。そのユーザーが複数の組織に属していても意味がなく、仮にそうであっても、別の組織に対しては別個の「アイデンティティ」を持つのが自然です。たとえば、2 つの異なる店舗でアルバイトをしている小売店の従業員は、両方の店舗が同じ SaaS アプリケーションを使用していても、それぞれの店舗に対して別々のログイン情報を持ちます。詳しくは、Provisioning users isolated to the organization を参照してください。組織間で共有する : この場合、ユーザーは自社で認証情報を作成するか、自身の組織の認証情報を使って、アプリケーションの他の組織インスタンスにアクセスできます。簡単に言えば、1 人のユーザーがアプリケーションの複数の組織インスタンスへのアクセスを許可される場合があります。ユーザーは、同じ認証情報を使ってアプリケーションの両方のインスタンスにアクセスできると理解できるはずです。たとえば、一部の医師は複数のクリニックと契約しており、同じ認証情報を使って各クリニックに個別にサインインできる必要がある場合があります。詳しくは、Provisioning users shared between organizations を参照してください。
ユーザーを組織ごとに分離すると、組織間に明確な境界を設けられます。どのユーザーも複数の組織にアクセスする必要がない場合 (または複数のアカウントを作成させたい場合) は、このアプローチが適しています。
こうしたユーザーは IdP レベルでプロビジョニングする必要があります。そのため、各組織はそれぞれ専用の IdP を持つことになります。この IdP は、次の 3 つのいずれかの形になります。
Auth0 テナントが IdP である場合 : メイン テナント内に、この組織専用の データベース接続 を用意します。組織が独自の IdP を持ち込む場合 : その組織向けに Enterprise Connection を設定します。複数の IdP を持つ組織の場合 : 複数の Enterprise Connection や Social Connection を有効にし、必要に応じて 1 つの データベース接続 を持つこともできます。ユーザーが自分の組織を選択してログインを試みると、その組織で有効になっているすべての接続から選択できます。
出発点としては、Auth0 を IdP として使用することを推奨します。これは、ユーザー招待ワークフロー を簡単に実装できるためです。ほかの招待フローと異なる点は、ユーザーを作成する担当者が事前に組織を選択する必要があるか、またはシステムによって、招待するユーザーと同じ組織に自動的に限定されることだけです (その組織のみに所属する組織管理者がいる場合など) 。
複数の組織でユーザーを共有する場合は、アクセスを認可する方法が必要です。認証時には、ユーザーがどの組織に属している可能性があるか事前には分からないため、通常はユーザーを単一のドメインに保存し、組織のメンバー として追加して、そのユーザーがアクセスできる組織を判断することを推奨します。そのため、プロビジョニングは多くの場合、単一のデータベース接続に対する User Invite ワークフローから始め、その後 Management API を使用してユーザーを組織に追加します。さらに、ユーザーが組織を切り替えられるようにする必要がある場合は、Management API を使用して、そのユーザーが所属する組織 を取得できます。
Auth0 に有効な SSO prompt=login で強制しない限り、Auth0 はアップストリームの IdP と通信しません。顧客組織のいずれかがそれらのユーザーのログアウトを管理できないと、ユーザーはデコミッション後も引き続きアクセスできる可能性があります。IdP によっては、Auth0 がその API 用のトークンを取得できる場合、ユーザーが引き続きアクセスできるべきかどうかを確認するために、Rules で IdP にユーザー情報をリクエストしてポーリングできます。この方法を利用できない場合は、API 呼び出しまたは UI を通じて、顧客組織がシステム内のユーザーをブロックまたは無効化できる手段を提供する必要があります。
ほとんどの B2B シナリオでは、アプリケーションへのアクセスを許可されるのは特定の個人に限られます。そのため、ユーザーがサインアップしてから管理者が承認するよりも、管理者がユーザーアカウントをプロビジョニングするほうが簡単な場合がよくあります。また、ユーザーが中央管理システムに追加されるタイミングで、プロビジョニングを自動化できることも少なくありません。
ユーザーを招待する 主体としては、次の 3 つが考えられます。
あなたの会社の管理者が、各組織のユーザーを作成する場合があります。
各組織の管理者が、ユーザー作成の担当者として割り当てられる場合があります。
ユーザー作成を担う別のシステムが存在し、そのシステムが Auth0 にユーザーを作成する場合もあります。オーディエンス
ユーザー招待に推奨される方法は、Organizations 機能 を使用することです。Organizations 機能を使用せず にユーザー招待を独自実装する場合は、各ユーザーを user.email_verified パラメーターを false に設定し、ランダムな一時パスワードを付与した状態で作成することが重要です。生成されたパスワードは Auth0 のみが知る状態にし、外部システムに保存したり、ユーザーに渡したりしてはいけません 。そのうえで、Management API を使用して、パスワードをリセットするためのリンクを含むメールをユーザーに送信します。さらに、これが招待によるサインアップフローの一部であることが分かるように、Auth0 でメールテンプレートを変更することもできます。これにより、そのメールアドレスが作成対象のユーザー本人のものであること、そしてパスワードを知っているのがユーザー本人だけであることを保証できます。
OIDC の主要な原則の 1 つは、ユーザー本人以外は誰もそのパスワードを知るべきではないということです。招待フローを実装する場合は、バックエンドシステムでランダムなパスワードを生成したらすぐに破棄し、ユーザーがログインする前にパスワードをリセットするようにしてください。一時パスワードを作成してユーザーに渡し、初回ログインに使わせてはいけません。
エンタープライズ サインアップは、エンタープライズ ログイン によるサインインと同義です。つまり、両者に実質的な違いはありません。これは、最初のエンタープライズ ログイン時にユーザーのプロファイル が自動的に作成されるためです。
ベストプラクティス 顧客が自社の IdP を利用できるようにするメリットの 1 つは、顧客向けの管理機能をあなたが構築しなくても、顧客自身が自社の IdP 構成内でユーザーを管理し、ロールやアクセスを割り当てられることです。そうした顧客向けのマッピングを整理しておくことで、この作業は大幅に簡単になります。 マッピングだけでは不十分で、何らかのメタデータをシステム側に保持する必要がある場合は、Auth0 ではユーザーが初めてそのシステムにログインするまでユーザーは作成されない点に注意してください。そのため、ルールの拡張機能を使用して別の場所から初期情報を取得するか、メタデータを追加できるようにする前に、ユーザーに初回ログインを行わせる必要があります。
推奨戦略の詳細を確認できるよう、PDF 形式の計画ガイドを提供しています。ダウンロードして参照してください。
B2B IAM プロジェクト計画ガイド 多くの B2B プラットフォームでは、顧客の組織ごとに何らかの分離やブランディングを実装しており、その結果、Identity and Access Management (IAM) システムが複雑になることがあります。これに当てはまる場合は、この種の環境に関するガイダンスとベストプラクティスをぜひご確認ください。
複数組織アーキテクチャ 
認証
ユーザー管理
カスタマイズ
Auth0 AI
プラットフォーム