> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Auth0 Organizations の仕組みを理解する

> Auth0 Organizations の仕組み、ユースケース、サンプルシナリオ、導入計画、制限事項について説明します。

<Card title="利用可否は Auth0 のプランによって異なります">
  この機能が利用可能かどうかは、ログイン実装の詳細と、Auth0 のプランまたはカスタム契約の両方によって異なります。詳しくは、[Pricing](https://auth0.com/pricing) をご覧ください。
</Card>

<div id="business-cases">
  ## ビジネスケース
</div>

Auth0 Organizations 機能は、エンドユーザーがアクセスするアプリケーションを持つ企業間取引 (B2B) の実装に特に適しています。

<Frame>
  <img src="https://mintcdn.com/translations/pvjQqAy3EB2TK6NP/docs/images/cdy7uua7fh8z/4l47Xknr2LpuMSOX0T3yCP/800877a39f474faa0c6d83551d56c337/b2b-business-case.png?fit=max&auto=format&n=pvjQqAy3EB2TK6NP&q=85&s=c9b314e2a2972105592186b3261ed3d5" alt="B2B Organizations のビジネスケース図" width="1600" height="1305" data-path="docs/images/cdy7uua7fh8z/4l47Xknr2LpuMSOX0T3yCP/800877a39f474faa0c6d83551d56c337/b2b-business-case.png" />
</Frame>

B2B 実装によく見られる特徴は次のとおりです。

* 他社の従業員による利用を目的としてライセンス提供される製品であること。
* 各 組織 で、認証エクスペリエンスに対して独自のフェデレーションと軽微な branding が必要になること。
* アプリケーション内のアクセスレベルを、各 組織 のメンバーに割り当てる roles で表現できること。

Organizations がどのように役立つのかを示すために、いくつかのビジネスケースの例を見ていきましょう。

<div id="sample-scenario">
  ## サンプルシナリオ
</div>

Travel0 はオンライン旅行サービスを提供する架空の企業で、Auth0 テナントを設定しています。Travel0 には複数のアプリケーションがありますが、ここでは Organizations を活用することでメリットが得られる 1 つのアプリケーションに注目します。

**Travel0 Adventure Management**: 顧客が急流ラフティング、乗馬、ジップラインなどのアドベンチャーを企画・販売できるオンラインアプリケーションです。各アドベンチャーにはガイドが付き、ガイドはこのアプリケーションを使って登録やスケジュール管理を行えます。ガイドは顧客に直接雇用されている場合もあれば、フリーランスの場合もあります。

このアプリケーションの顧客には、次のような企業があります。

* **Granite Outpost Rafting and Ziplines**: 大勢のガイドスタッフを直接雇用している老舗企業ですが、ときどきフリーランスのガイドにも声をかけています。従業員向けに独自の <Tooltip tip="IDプロバイダー（IdP）: デジタルアイデンティティを保存および管理するサービス。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=IdP">IdP</Tooltip> を利用しています。
* **AdventureZ**: 多数のガイドを直接雇用している大規模なイベント会社ですが、頻度は低いもののフリーランスも活用しています。また、ガイドを必要としている他社向けに、自社の従業員がフリーランスとして働けるようにもしています。従業員向けに独自の IdP を利用しています。
* **Rocky Mountain High Adventures**: 市場に参入したばかりの新しい会社です。共同創業者がツアーの大半を運営しており、繁忙期にはフリーランスにサポートを依頼しています。IT スタッフはおらず、独自のアイデンティティプロバイダー (IdP) を設定する時間も、その意向もありません。AdventureZ と契約を結んでおり、AdventureZ の従業員であれば誰でも同社のためにフリーランスとして働けます。

<div id="planning-considerations">
  ## 計画時の考慮事項
</div>

組織を設定する際は、次の点を考慮してください。

* **ログイン体験**: ユーザーはログイン時に組織を選択する必要がありますか？ ユーザーには、アプリケーションのデフォルトのログインページが表示されますか、それとも組織向けにカスタマイズされたログインページが表示されますか？
* **接続モデル**: 組織間で共有されるユーザーはいますか？ ユーザーは、組織独自の内部アイデンティティプロバイダーを使用してログインできる必要がありますか？
* **ロール**: アプリケーションでは、ユーザーに各組織内で特定のロールが割り当てられている必要がありますか？ 割り当てられたロールを使用して、管理者が自分の組織をセルフサービスで管理できるカスタムダッシュボードを構築する予定はありますか？

<div id="login-experience">
  ### ログイン体験
</div>

まず、ユーザーが組織にログインする際にどのような体験にするかを決める必要があります。エンドユーザーをAuth0内の特定の組織のログインプロンプトに直接送ることも、ログインしたい組織の名前を入力できるプロンプトに送ることもできます。

さらに、アプリケーション用に設定されたデフォルトの<Tooltip tip="Universal Login: アプリケーションは、ユーザーの本人確認を行うために、Auth0 の認可サーバーでホストされている Universal Login にリダイレクトします。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Universal+Login">Universal Login</Tooltip>ページを使用するか、ページテンプレートを使って組織ごとに専用のログインページをカスタマイズするかを選ぶ必要があります。詳しくは、[Create Your First Organization](/docs/ja-jp/manage-users/organizations/create-first-organization)を参照してください。

<div id="connection-model">
  ### 接続モデル
</div>

通常、各 組織 はビジネス上の顧客やパートナーのいずれか 1 つに直接対応しますが、ユーザーは複数の組織のメンバーになることができます。ユーザーが顧客の組織にどのように対応づけられるかを理解することで、組織と接続をどのようにモデル化すべきか判断しやすくなります。ユーザーのシナリオは 2 つあります。

* **ユーザーが 1 つの 組織 に限定される場合**: すべてのユーザーは、必ず 1 つの 組織 のみに所属します。ユーザーが複数の 組織 に所属する必要がまったくない場合や、組織 ごとに別の ID を作成したほうが適切な場合です。
* **ユーザーが複数の 組織 間で共有される場合**: どのユーザーも複数の 組織 に所属でき、同じ ID を使って 組織 間を移動できる必要があります。

Travel0 Adventure Management の例で、次のユーザーを想定してみましょう。

* **Jonno**: Rocky Mountain High Adventures に直接雇用されているガイドで、Rocky Mountain の 組織 にのみログインできる必要があります。
  Rocky Mountain には独自の IdP がないため、Jonno の資格情報は Travel0 のデータベース接続に保存され、Jonno には Rocky Mountain 組織 のメンバーシップが割り当てられます。
* **Hiroko**: Granite Outpost Rafting and Ziplines に直接雇用されているガイドで、Granite Outpost の 組織 にのみログインできる必要があります。
  Granite Outpost には独自の IdP があるため、Hiroko の資格情報は Travel0 のデータベース接続、または Granite Outpost が自社の IdP を表すために設定したエンタープライズ接続のいずれかに保存できます。そのうえで、Hiroko には Granite Outpost 組織 のメンバーシップも割り当てる必要があります。Granite Outpost の IdP を使用する場合は、そのエンタープライズ接続もその 組織 に対して有効化されていなければなりません。
* **Emilio**: Rocky Mountain High Adventures と Granite Outpost Rafting and Ziplines の両方でフリーランスとして働くガイドで、両方の 組織 にログインできる必要があります。
  Emilio が両方の 組織 で同じ資格情報を使えるようにしたい場合は、Emilio の資格情報を Travel0 のデータベース接続に保存し、Emilio には Rocky Mountain 組織 と Granite Outpost 組織 の両方のメンバーシップを割り当てる必要があります。
  そうでない場合、Emilio は Rocky Mountain High Adventures 用に Travel0 のデータベース接続で 1 組の資格情報を設定し、Rocky Mountain High 組織 のメンバーシップを割り当てられる必要があります。そのうえで、Travel0 のデータベース接続または Granite Outpost のエンタープライズ接続のいずれかで別の 1 組の資格情報を設定し、Granite Outpost 組織 のメンバーシップを割り当てられる必要があります。最後に、Granite Outpost の IdP を使用する場合は、設定済みのエンタープライズ接続を Granite Outpost 組織 に対して有効化する必要があります。
* **Sumana**: AdventureZ に直接雇用されているガイドですが、AdventureZ と Rocky Mountain の契約のもと、ときどき Rocky Mountain High Adventures でもフリーランスとして働きます。AdventureZ と Rocky Mountain にはガイドの評価システムがあり、Sumana の評価は AdventureZ から Rocky Mountain に引き継がれ、組織 間で統合される必要があります。
  Sumana の資格情報を Travel0 のデータベース接続に保存し、Rocky Mountain 組織 と AdventureZ 組織 の両方にメンバーシップを割り当てることもできます。あるいは、AdventureZ が自社の IdP を共有したい場合は、Sumana の資格情報を AdventureZ が自社の IdP を表すために設定したエンタープライズ接続に保存し、そのエンタープライズ接続を Rocky Mountain 組織 と AdventureZ 組織 の両方に対して有効化する必要があります。
  さらに Sumana が Granite Outpost Rafting and Ziplines でもフリーランスをするよう招待された場合、彼女の資格情報は Travel0 のデータベース接続に保存することも、Granite Outpost の IdP に追加することもでき、Granite Outpost 組織 のメンバーシップを割り当てる必要があります。

いくつの組織を持つか、また接続モデルをどのような形にするかを決定したら、[データベース](/docs/ja-jp/authenticate/database-connections)、[ソーシャル](/docs/ja-jp/authenticate/identity-providers/social-identity-providers)、または [エンタープライズ](/docs/ja-jp/authenticate/identity-providers/enterprise-identity-providers) 接続を設定し、[組織を作成](/docs/ja-jp/manage-users/organizations/configure-organizations/create-organizations) し、[組織のメンバーシップを設定](/docs/ja-jp/manage-users/organizations/configure-organizations/invite-members) するか、[組織の接続を有効化](/docs/ja-jp/manage-users/organizations/configure-organizations/enable-connections) できます。

<div id="application-access-model">
  ### アプリケーションのアクセスモデル
</div>

デフォルトでは、Organizations が有効でアクティブな接続が設定されているすべてのアプリケーションに、組織のメンバーがアクセスできます。これが暗黙的なアクセスモデルです。

[アプリケーションごとのアクセス](/docs/ja-jp/manage-users/organizations/configure-organizations/grant-application-access)を使用すると、個々の組織を明示的なアクセスモデルに切り替えられます。組織で有効にすると、明示的なグラントがないファーストパーティアプリケーションはブロックされます。明示的なグラントがないサードパーティアプリケーションは、引き続きその組織の Third-Party Application Access ポリシーに従います。テナント内の他の組織には影響しません。

次のような場合は、明示的なモデルを使用してください。

* 特定の顧客組織が購入した製品へのアクセスを制限する。
* 組織にプロビジョニングされていないアプリケーションにメンバーがアクセスできないようにする。
* カスタム Actions や `app_metadata` による回避策を使わずに、アプリケーションの利用権限を管理する。

はじめに、[組織へのアプリケーションアクセスの付与](/docs/ja-jp/manage-users/organizations/configure-organizations/grant-application-access)を参照してください。

<div id="roles">
  ### ロール
</div>

組織のメンバーには、[ロールを割り当てる](/docs/ja-jp/manage-users/organizations/configure-organizations/add-member-roles)ことができます。これらのロールを使って、アプリケーションのアクセス制御を定義できます。たとえば、API と SDK を使用してユーザー向けのダッシュボードを構築した場合、特定のメンバーに管理者ロールを割り当て、ダッシュボードを通じて自分たちの組織を管理できるようにすることができます。

<Warning>
  Management API には、confidential クライアントからのみアクセスする必要があります。その利用には、[Auth0 Management API のレート制限](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy/management-api-endpoint-rate-limits)が適用されます。
</Warning>

<div id="limitations">
  ## 制限事項
</div>

Auth0 Organizations 機能には、次の制限事項があります。

* この機能を利用できるかどうかは、ご利用の Auth0 のサブスクリプションプランによって異なります。詳しくは、[Auth0 Pricing](https://auth0.com/pricing/)をご覧ください。
* Universal Login でのみサポートされます (クラシックログインおよび Lock.js はサポート対象外です) 。
* Organizations が有効化されたアプリケーションは、次のグラントおよびプロトコルと互換性がありません: <Tooltip tip="Web Service Federation (WS-Fed): ドメイン間でユーザー ID を管理するためのプロトコル。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Resource+Owner">リソース所有者</Tooltip> パスワード、Device <Tooltip tip="リソース所有者: 保護されたリソースへのアクセスを許可できるエンティティ（ユーザーやアプリケーションなど）。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Authorization+Flow">Authorization Flow</Tooltip>、<Tooltip tip="Authorization Flow: OAuth 2.0 フレームワークで規定されている認可グラント（またはワークフロー）。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=WS-Fed">WS-Fed</Tooltip> (Auth0 を IdP として使用する場合) 。
* サポートしていないもの:

  * 組織 ごとのカスタムドメイン (たとえば、サンプルシナリオのように Rocky Mountain High Adventures と Granite Outpost Rafting and Ziplining の両方でログインドメインとして `login.travel0.com` を使用できるのであれば、Organizations は有用です。一方、Rocky Mountain High Adventures が `login.rockymountain.com` を使用し、Granite Outpost が `login.graniteoutpost.com` を使用したい場合は、複数の Auth0 テナントを使用する必要があります。)
  * Delegated Administration Extension との連携。
  * Authorization Extension との連携。

サードパーティアプリケーションは Organizations でサポートされています。組織でサードパーティアプリケーションを有効にする方法については、[組織のサードパーティアプリケーションアクセスを有効にする](/docs/ja-jp/manage-users/organizations/configure-organizations/enable-third-party-application-access)をご覧ください。

<div id="learn-more">
  ## 詳しくはこちら
</div>

* [最初の組織を作成する](/docs/ja-jp/manage-users/organizations/create-first-organization)
* [Organizations を利用したカスタム開発](/docs/ja-jp/manage-users/organizations/custom-development)
* [トークンと Organizations を扱う](/docs/ja-jp/manage-users/organizations/using-tokens)
* [Organizations を設定する](/docs/ja-jp/manage-users/organizations/configure-organizations)
* [エンティティ上限ポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/entity-limit-policy)