アーキテクチャを計画する
設計におけるベストプラクティスを確立し、アーキテクチャを計画するには、さまざまな視点からニーズを考慮してください。基盤となる技術や機能だけでなく、最終目標とワークフローに焦点を当てましょう。ここでは、製品の理想的なアーキテクチャを構築する際に役立つ重要な質問をいくつか紹介します。
ビジネスモデルは何ですか？関与する主要な関係者やステークホルダーは誰ですか？
一般的に、2 つの主要なビジネスモデル、B2C と B2B があり、それぞれが複雑なアイデンティティ管理シナリオにおいて異なる関係者を含みます。これらの主要なステークホルダーを理解することで、ユーザー中心の体験を提供し、アイデンティティ管理のすべての側面に対応するシステムを設計するのに役立ちます。
B2C
B2C アプリケーションでは、アイデンティティ管理は通常シンプルで、通常は 2 つの関係者のみが関与します。
開発者 (あなた)
これは、Logto コンソールの管理者と協力者 を指します。通常、あなたと開発チームがユーザーアイデンティティプールを管理し、保護し、アイデンティティデータベースと直接連携します。Logto コンソールで顧客のアイデンティティを直接管理するか、Logto Management API を使用してカスタム開発を行うことができます。
あなたの消費者
あなたの消費者は、Logto のコアサービスとデータベースに保存されているユーザーアイデンティティです。B2C モデルでは、消費者は自分の認証 (Authentication) と個人情報を管理できます。
B2B
B2B アプリケーションでは、このアーキテクチャに別のレイヤーとコンテキストが導入されます。ビジネスユニットの所有者（または組織）が、誰がインスタンスにアクセスできるか、どのように認証 (Authentication) するか、何ができるかを制御します。組織は、インスタンスにアクセスするすべてのエンドユーザーのアイデンティティを管理します。
開発者 (あなた)
これも依然として Logto コンソールの管理者と協力者 を指します。組織の管理者がアイデンティティを管理できる一方で、開発者は Logto コンソールで顧客のアイデンティティを直接管理したり、Logto Management API を使用してカスタム開発を行ったりできます。
あなたのクライアント (組織の管理者)
あなたのクライアントは、マルチテナントアプリにおける「組織」を表すビジネスユニットです。例えば、Slack や Notion の ワークスペース です。各ワークスペースには通常、複数のロールと、従業員やユーザーを管理する 1 人以上の管理者がいます。以下の内容では、メンバーのアイデンティティを管理できる人を「組織の管理者」と呼びます。
あなたのクライアントのスタッフ、パートナー、または消費者
これらは、組織のコンテキストで「メンバー」と呼ばれるエンドユーザーのアイデンティティであり、組織内で管理できます。これらのアイデンティティは組織によって分離されていますが、すべて単一のアイデンティティシステムの下に集約されています。
実際のシナリオでは、製品の観点から、これらは会社のスタッフ、ビジネスパートナー、または組織に関連する消費者である可能性があります。
その他
B2B2C のような他のモデルは、その複雑さからこれら 2 つから派生することがあります。しかし、アプローチは同じです：すべての変更は同じコア基盤から生じます。
次の章では、これら 2 つの一般的なアーキテクチャを詳しく見て、Logto がサポートする関連機能を強調します。
認証 (Authentication) のニーズを明確にする
技術と製品設計に関与する主要なユーザーと関係者を理解したら、次の質問を考慮してアイデンティティアーキテクチャを洗練し、認証 (Authentication) のニーズと制御レベルを決定してください：
-
顧客はどのような認証 (Authentication) オプションとサインイン体験を持っていますか？これらは通常、ビジネス、獲得戦略、製品のニーズに依存します。
例：私のアプリにはどの機能が必要ですか？ソーシャルサインイン？パスワードレスログイン？
-
顧客の行動に対してどの程度の制御を持ちたいですか？
例：顧客は自分のプロフィールを更新し維持できますか？顧客は自分で MFA をオンオフできますか？好みのサインイン方法を選択できますか？
-
組織にどのようなカスタマイズを委任したいですか？これらは製品のドメインと業界、およびクライアントの特定のニーズに依存し、組織ごとに異なる場合があります。
例：サインイン体験は各組織ごとに異なるべきですか？そうである場合、カスタマイズはブランディングに限定されるべきですか、それとも認証 (Authentication) フローの違いも含むべきですか？
-
組織の管理者にメンバーの行動に対してどの程度の制御を持たせたいですか？
例：組織の管理者は MFA が必要かどうかを決定できるべきですか？管理者はメンバーのパスワードを変更する能力を持つべきですか？
単一のユニバーサルアイデンティティシステムが必要ですか、それとも複数の別々のものが必要ですか？
もう一つの重要な質問は、ビジネスや製品の一部が単一のアイデンティティシステムを必要とするか、別々のものを必要とするかを自問することです。
通常、答えは単一のユニバーサルアイデンティティシステムであり、つまり、1 つの Logto テナント（または Logto OSS の 1 つの Logto 管理コンソールインスタンス）のみが必要です。Logto は、単一のテナント内で複数のアプリケーションと複数の組織の両方をサポートするように構築されています。1 つの本番 Logto テナントは、ほとんどのニーズに対して通常十分です。ここでは、直面する可能性のある一般的なシナリオをいくつか紹介します：
マルチテナンシーを持つ SaaS アプリケーションを構築したい
各顧客のために「ワークスペース」または「組織」の概念を持つ SaaS アプリケーションを構築している場合、単一のテナント内で各顧客のワークスペースを管理するために組織を使用できます。
この場合、ユーザーは複数の組織のメンバーになることができます。例えば、ユーザーは個人のワークスペースを持ち、会社のワークスペースに参加することができます。
複数のアプリケーションを持っている
Logto を使用すると、アプリケーションの種類（例えば、ウェブ、モバイル、デスクトップなど）やアプリケーションのユースケースと機能（例えば、ドライバーアプリ、ハイラーアプリなど）に関係なく、単一のテナント内で複数のアプリケーションを管理できます。
複数の企業顧客を持っている
エンタープライズ SSO を使用して、単一のテナント内で複数の企業顧客を管理するために組織を使用できます。エンタープライズ SSO のメールドメイン設定を構成し、ジャストインタイムプロビジョニング機能を使用することで、エンタープライズ SSO アカウントを持つユーザーが適切な組織に参加またはサインインするプロセスを自動化できます。