💨

Auth0のTeams・Tenant・Organization・マルチテナントをつまづかずにざっくり理解する

に公開
zennfes2025infra
tech

はじめに

これまで認証認可のサービスは主にAuth.jsを使ってきましたが、Auth0を使って開発することになり認証基盤としての機能の多さに四苦八苦している日々です。
単にアプリに認証認可機能を組み入れるだけならそこまで深掘りする必要はありませんが、企業ごとに認証基盤を用意するなど仕様に合った設計をするのであれば様々な機能を理解しなければなりません。
特にTeams・Tenant・Organization・マルチテナントあたりの機能の性質はしっかり理解しておかないと後々つまづきかねないと感じたので、今回記事にすることにしました。

この記事を読んでもらいたい人

  • 初めてAuth 0を使った認証基盤サービスに関わることになり、まずは全体概要をサクッと知りたい方
  • 日頃何気にAuth 0を使っているが、改めて主要な仕組みを理解したい方
  • Auth 0に関心がある方

1. Teams

こちらの公式ドキュメントにもあるとおり、Teamsは集中型のガバナンス、コンプライアンス、大規模なスケールにも対応した安全なコラボレーションを提供することにより、Auth0リソースに対する単一の可視性と管理を実現するものです。
機能の説明として

  • 複数のTenantの一元管理
  • テナントメンバーの表示と管理
  • 独自のIDプロバイダーを使用してシングルサインオンを強制
  • テナントの作成を制限
  • サブスクリプションと請求の管理
    とありますが、開発する上ではまず「テナントごとにメンバー管理をしながら一元管理する最上位の管理機能」と考えるといいのではないかと思います。

TeamsとTenantの関係は公式にも図はありますが、体系図の方がわかりやすいかと思います。
Auth0 Teamsの構造：

Auth0 Teams（管理者向け機能）
│
├─ Team Owner（チーム所有者）
│  └─ 複数のTenantを管理できる権限
│
└─ 管理対象のTenants
   ├─ Tenant A（本番環境）myapp-prod.auth0.com
   ├─ Tenant B（開発環境）myapp-dev.auth0.com
   └─ Tenant C（ステージング）myapp-staging.auth0.com

Teamsのメンバー（チーム所有者）が複数のTenantsの管理をする例です。
チーム所有者は各テナントの管理者を割り当てします。

2. Tenant（テナント）

Tenantとは認証に必要なすべての設定とデータを管理する認証基盤です。
認証管理に必要な以下の機能が備わっています。

簡単な機能説明

要素 説明 主な例
Users すべてのユーザーアカウント情報 Organizationに関わらず全てのユーザー管理
Applications 認証を行うアプリケーションの設定 SPA、Web App、Mobile App、M2M
APIs 保護するAPIリソースの定義 Management APIまたはカスタムAPI
Authentication 認証方法の設定 ソーシャル認証の設定やデータベース接続など
Organizations 企業・グループの論理的な分離 企業別にBrandingなどを個別設定
Branding ログイン画面のカスタマイズやカスタムドメインなど 企業ロゴ、カラー、カスタムテキスト
Security セキュリティ管理 MFA、パスワード漏洩対策など
Settings テナントの全体設定 請求やテナントメンバーの管理など

3. Organization（組織）

Organizationとは、Tenant内で企業・グループごとにユーザーを論理的に分離する機能です。
言い換えるとユーザーごとに所属組織を設定する機能です。
Tenantとの関係は図や表のほうがわかりやすいかと思います。
関係を図示すると以下のような感じになります。

Auth0 Tenant (myapp.auth0.com)
│
├── Users（全ユーザーデータベース）
│   ├── user1@companyA.com
│   ├── user2@companyA.com
│   ├── user1@companyB.com
│   └── freelancer@gmail.com
│
└── Organizations（企業ごとのグループ）
    │
    ├── Organization A (企業A)
    │   ├── Members: user1@companyA.com, user2@companyA.com
    │   ├── Branding: 企業Aのロゴ・カラー
    │   ├── IdP: Azure AD (companyA.com専用)
    │   └── Roles: Admin, Member
    │
    ├── Organization B (企業B)
    │   ├── Members: user1@companyB.com,freelancer@gmail.com
    │   ├── Branding: 企業Bのロゴ・カラー
    │   ├── IdP: Google Workspace
    │   └── Roles: Viewer, Editor
    │
    └── Organization C (企業C)
        ├── Members: freelancer@gmail.com  ← 複数のOrgnizationに所属
        └── ...                              所属可能

特徴

  • Organizationはユーザーへの参照権を持つ
  • 1人のユーザーが複数のOrganizationに所属可能（上図のfreelancer@gmail.comのように複数企業に所属可能）
  • 企業ごとに異なるブランディング（ログインやカスタムドメインなど）やIdP（ソーシャルログイン）設定が可能
    となります。

違いを表でまとめてみました。

項目 Tenant Organization
階層 最上位 Tenant内の1要素
数 サービスに対して1つ（本番用/テスト用などの分割はあり） 複数（企業の数だけ）
スコープ アプリ全体 特定の企業・グループ
ユーザー管理 すべてのユーザー 企業ごとにフィルタリング
用途 認証基盤全体の管理 B2Bマルチテナント実装
データ分離 物理的に完全分離 論理的に分離（アプリで実装）

4. マルチテナント

上の表で「マルチテナント」とでできましたが、マルチテナントとはなんでしょうか。
私は文字通りテナント（Auth0 Tenant）を複数管理するものという間違った先入観が拭えず苦労しましたが、マルチテナント = 単一のアプリケーションで複数の企業（テナント）にサービスを提供すること
と考えるといいかと思います。
この「単一のアプリケーションで複数の企業（テナント）にサービスを提供すること」を実現するために「単一のTenant」で「複数の企業（Organization）」という形で機能を利用します。

⚠️ マルチテナントはAuth0 Tenantの複数管理とは異なります。注意しましょう

5. AWSとの比較で理解する

Organizationをみた時に「AWSと同じようなもの？」とぼんやり思ってしまったのもつまづきポイントでした。
Auth 0とAWSではOrganizationの性質が違います。
表にしました。

概念 Auth0 AWS 備考
最上位の管理単位 Tenant Organization Auth 0の最上位はTenant
分離された実行環境 Organization Account Organizationで企業を管理している
論理的なグループ Roles/Groups IAM Group 権限管理の性質は類似

このように、Organizationのレベルが異なります。言葉に惑わされないようにしましょう。

構造の比較図

Auth0の構造

Auth0 Tenant (最上位: 認証基盤全体)
 ├─ myapp.auth0.com というドメイン
 ├─ すべてのユーザーを一元管理
 │
 └─ Organizations (企業ごとの論理分離)
     ├─ Organization A (企業A)
     │   └─ 企業Aのユーザー・設定
     ├─ Organization B (企業B)
     │   └─ 企業Bのユーザー・設定
     └─ Organization C (企業C)
         └─ 企業Cのユーザー・設定

💡 ポイント: 
- 全データは同じデータベースに保存
- Organizationは「色分け」「ラベル付け」に過ぎない
- データの物理的分離はアプリ側で実装

AWSの構造

AWS Organization (最上位: 複数アカウントの管理)
 ├─ マスターアカウント（請求・管理用）
 │
 └─ 各アカウント(環境・プロジェクトごとの物理分離)
     ├─ Account A (本番環境)
     │   └─ 完全に独立したリソース
     ├─ Account B (開発環境)
     │   └─ 完全に独立したリソース
     └─ Account C (テスト環境)
         └─ 完全に独立したリソース

💡 ポイント:
- 各Accountは物理的に完全分離
- AWSが自動的にリソースを分離
- Account間のアクセスは明示的な設定が必要

Auth 0がAWSと決定的に違うのは、「Organizationによるユーザーの分離が論理分離でAWSアカウントのような物理分離ではない」ところかとも思います。
ですので呼び出しするアプリ側でOrganizationを特定してデータフェッチをする必要があります。

最後に

Auth 0の初歩的な話が中心でしたが、用語にとらわれて序盤でつまづかないための一助となれば幸いと思い記事を書きました。
そもそも日頃フロントエンドやバックエンドのアプリ開発しかしていなかったので認証基盤の概念やアーキテクトに対する理解が不足していたことを痛感しました。
認証基盤を学ぶのは根気が必要と感じていますが、大切なことなので今後もしっかり学習を続けていきたいと思います。

Discussion