本記事は「Multi-Tenant SaaS Apps with Auth0 Organizations — Part 1」を翻訳した記事です。
架空の急成長中のクラウドネイティブなプロジェクト管理SaaSプラットフォームであるFlowGridを紹介します。多くの現代のスタートアップと同様に、FlowGridの初期の成功はProduct-Led Growth(PLG)によって牽引されました。個人ユーザーや小規模チームは、基本的なパスワードやソーシャルログインを使用して、個人または仕事用のメールアドレスでサインアップしました。運用はシンプルで、ユーザーベースは成長していました。
しかしその後、FlowGridは転換点を迎えました。営業チームが、Fortune 500に名を連ねるAcme Corp(別の架空の企業)という初めての主要な見込み客を獲得したのです。AcmeのCISOはFlowGridに最後通牒を突きつけました。
“”
FlowGridのリードアーキテクトは、自社開発のカスタムusersテーブルが、エンタープライズシングルサインオン(SSO)、ドメインルーティング、マルチテナント認可の負荷に耐えきれず崩壊しそうになっていることに気づきました。
FlowGridは、B2Bブログ記事シリーズ全体を通して架空の企業として登場します。シリーズでは、Auth0を使用してB2B SaaSエクスペリエンスを保護することに関連するすべての事項を網羅します。エンタープライズオンボーディング、SaaSマルチテナントアーキテクチャ、認可などが含まれます。
Auth0 Organizationsは、まさに直面している課題に対するソリューションです。全5回のシリーズの第1回となる本記事では、以下の内容について説明します。
- Auth0 Organizationsとは何か
- B2CおよびB2Bのユースケースにおけるログインフローの仕組み
- ユーザーを適切なアイデンティティプロバイダーにルーティングする方法
- 組織レベルで認可をモデル化する方法
What Are Auth0 Organizations and When to Use Them
エンタープライズ契約を獲得するには、データとアクセスの分離を証明する必要があります。Auth0 Organizationsは、SaaS製品内の隔離されたワークスペースであるテナントを表します。企業、ワークスペース、または顧客アカウントなどが該当します。
各Organizationには独自の設定があります。
メンバー: 特定のOrganizationに属するユーザー。
Connections: Organizationが使用するアイデンティティプロバイダー(Google Workspace、Okta、Microsoft Entra ID、Auth0独自のデータベースなど)。
メタデータ: テナント設定用の任意のキーバリューストア。
ロールと権限: Organizationのメンバーシップ専用にスコープされたアクセス制御。
When to use Auth0 Organizations
ユーザーが企業の一員としてログインし、企業のコンテキストによってユーザーを分離する必要がある場合は、Organizationsを使用します。典型的な指標は以下のとおりです。
独自のIdPを使用したSSOを希望するエンタープライズ顧客がいる。
ユーザーが複数のテナントに属する可能性がある(2つの異なるクライアントで働く請負業者など)。
グローバルなユーザーロールとは別に、テナントレベルのアクセス制御が必要である。
Auth0 Organizationsは適切なB2Bアイデンティティを実装するために必要なすべての機能を提供するため、製品チームは長い実装サイクルを省略し、適切なエンタープライズ対応をすぐに利用できます。
When not to use Auth0 Organizations
すべてのユーザーがテナントコンテキストを持たない個人である純粋なB2Cアプリでは、Organizationsは必要ない場合があります。消費者向けのフィットネスアプリにはOrganizationsは不要ですが、チーム向けに販売されるプロジェクト管理ツールには必要です。
Supporting Self-Service and Enterprise Customers at Once
FlowGridは、セルフサービスユーザーとエンタープライズ層の両方を1つのコードベースでシームレスにサポートする必要があります。認可リクエストのorganizationパラメーターは、B2CとB2Bのログイン動作の分岐点となります。
B2C with no organization parameter
ユーザーはOrganizationコンテキストなしでUniversal Loginを通過します。FlowGridのフリーミアム層、個人のサインアップ、企業アカウントがプロビジョニングされる前のトライアルに最適です。
B2B with an organization parameter
organizationを渡すと、Auth0はログインエクスペリエンス全体をOrganizationにスコープします。
Organizationで有効になっているConnectionsのみが利用可能です。
設定されている場合、ブランディング(ロゴ、色)はOrganizationを反映します。
生成されたトークンには
org_idおよびorg_nameクレームが含まれます。
不透明なIDの代わりに、Organizationの名前スラッグとしてorganizationを渡せます。アプリのルーティングからログインURLを構築する場合に便利です(例: acme.yourapp.com → organization=acme)。
Inviting a user into the Organization
ユーザーをOrganizationに招待すると、Auth0は招待チケットを生成します。受信者がリンクをクリックしてサインアップまたはログインを完了すると、自動的にOrganizationに移動します。招待では、フロー全体を通してorganizationパラメーターが保持されます。シリーズの後半では、System for Cross-domain Identity Management(SCIM)などのエンタープライズグレードのプロトコルに焦点を当てます。
How Does Auth0 handle Home Realm Discovery?
Acme Corpの従業員がFlowGridにアクセスする場面を想像してください。AcmeのITポリシーではパスワードが厳格に禁止されています。ユーザーがログインページでメールアドレスを入力した際、どのIdPに送信するかを判断する必要があります。これがHome Realm Discovery(HRD)です。
Auth0はConnectionレベルでHRDを処理します。OrganizationでConnectionが有効になっている場合、Auth0はメールのドメインを使用してユーザーをConnectionに自動的にマッピングします。機能を使用するには、Authentication ProfileをIdentifier Firstに設定する必要があります。
フロー。
ユーザーがUniversal Loginでメールアドレスを入力します。
Auth0は、ドメインがアクティブなOrganization(Organizationが事前に選択されていない場合はすべてのOrganization)で有効になっているConnectionと一致するかどうかを確認します。
一致が見つかった場合、Auth0はパスワード画面をスキップしてエンタープライズIdPに直接リダイレクトします。
エンタープライズが一致しない場合は、デフォルトのConnection(データベース、ソーシャルなど)にフォールバックします。
多くのB2Bアプリでは、テナント固有のURL(例: acme.yourapp.com)を使用して、ユーザーがログイン画面を見る前にorganizationパラメーターを事前に入力します。Auth0は確認すべきOrganizationをすでに把握しているため、HRDの信頼性が高まります。
HRDにより「どのようにログインすればよいか」というサポートチケットが不要になり、CISOを満足させるエンタープライズグレードのログインエクスペリエンスを提供します。
Tenant Context Switching Pattern
FlowGridには、Acme CorpとGlobexの両方のプロジェクトを管理する代理店コンサルタントがいます。複数のOrganizationに属するユーザーには、ログアウトせずにコンテキストを切り替える方法が必要です。
Auth0は特定のOrganizationにスコープされたトークンを発行します。アクセストークンのorg_idクレームは、どのテナントコンテキストがアクティブであるかをAPIに伝えます。テナントを切り替えるには、ユーザーは異なるorg_idを持つ新しいトークンを必要とします。
異なるorg_idを含む新しいトークンを発行するには、「organizationパラメーターありのB2B」セクションですでに説明したように、organizationパラメーターを使用します。
サイレント認証が失敗した場合(セッションの有効期限切れなど)、表示されるリダイレクトにフォールバックします。ユーザーは、ターゲットOrganizationに事前スコープされたログイン画面に移動します。
Mapping Tenants to Data
Auth0 Organizationsをアプリケーションのデータモデルにマッピングするには、大きく分けて2つのパターンがあります。
One Auth0 Organization per app tenant (recommended for B2B)
各顧客企業は1つのAuth0 Organizationを取得します。アプリケーションデータベースは、すべてのテナントスコープデータの外部キーとしてorg_idを保存します。
例。
App Tenant: Acme Corp └── Auth0 Org: orgpageviews_abc123 ├── Members: [alice@acme.com](mailto:alice@acme.com), [bob@acme.com](mailto:bob@acme.com) ├── Connection: Acme's Okta (SAML) └── Metadata: { plan: "enterprise", region: "us-east" }
無駄のない分離、わかりやすい認可、特定のOrganizationのすべてのデータを簡単にクエリできる環境を提供します。
Shared Auth0 Organization with custom claims (not recommended)
一部のプラットフォームでは、Organizationsを使用する代わりに、Actionsを介してカスタムクレームにテナントコンテキストをエンコードします。機能しますが、アプリケーション層に複雑さを押し付けることになります。Organizationsがすでに提供しているものを再発明している状態です。特定の理由がない限り、避けてください。
Tokens, Scopes, Roles, and Claims
ユーザーがOrganization内で認証されると、認可が重要になります。FlowGridは、ユーザーがAcmeではAdminであり、Globexでは単なるViewerであることを保証する必要があります。
Organization-level roles
Auth0では、ユーザーが持つ可能性のあるグローバルロールとは別に、Organization内のユーザーにロールを割り当てられます。ロールは権限に解決され、権限はアクセストークンのクレームとして表示されます。ただし、トークンがOrganizationのコンテキストで発行された場合に限ります。
Organization claims in tokens
デフォルトでは、APIでRole-Based Access Control(RBAC)が有効になっている場合、Organizationで認証されたトークンにはorg_idと権限クレームが含まれます。APIはorg_idを使用してデータクエリをスコープし、権限を検証して操作を制御します。
Auth0 Actions for custom claims
Auth0 Actions(Post-Login flow)を使用して、event.organization.metadataから直接、Organization固有のメタデータ(プラン層、リージョン、機能フラグなど)でトークンを強化します。リクエスト時にManagement APIへの余分なラウンドトリップを回避できます。
What Is Next?
本記事では、Organizationsとは何か、ログインフローの仕組み、HRD、テナントアーキテクチャ、Organizationスコープの認可など、コアとなるメカニズムについて説明しました。基礎となる部分です。
パート2では、運用面についてさらに深く掘り下げます。
- セルフサービスSSO
- My Organization API
- Management APIラッパーをゼロから構築することなく、製品の管理インターフェイスを通じてエンタープライズ顧客が独自のユーザーとConnectionsを管理できるようにする方法
Ready to Level Up Your SaaS Architecture?
開発を止めて、ページビューを体験し始めましょう。 B2BアイデンティティのインタラクティブなハンズオンマスタークラスであるSaaStartにアクセスしてください。数分で最初のOrganizationをプロビジョニングし、エンタープライズConnectionsを有効にして、実際のトークンを発行できます。パート2で運用の詳細に飛び込む前に、Auth0を利用したSaaSアプリケーションを体験してください。
まだAuth0アカウントをお持ちでない場合は、無料で作成してください。