メインコンテンツへスキップ

利用可否は Auth0 のプランによって異なります

この機能を利用できるかどうかは、ログイン実装の構成と、Auth0 のプランまたはカスタム契約の両方に左右されます。詳しくは、Pricing を参照してください。

​
ビジネスケース

Auth0 組織機能は、エンドユーザーがアクセスするアプリケーションを持つ企業間取引 (B2B) の実装に特に適しています。
B2B Organizations ビジネスケース図
B2B 実装によく見られる特徴は次のとおりです。
  • 製品が、他社の従業員による利用を目的としてライセンス提供されている。
  • 各組織で、それぞれ独自のフェデレーションと、認証エクスペリエンスに対する軽量なブランディングが必要になる。
  • アプリケーション内のアクセスレベルは、各組織のメンバーに割り当てられたロールで表現できる。
組織がどのように役立つのかを示すため、いくつかのビジネスケースの例を見ていきましょう。

​
サンプルシナリオ

Travel0 は、オンライン旅行サービスを提供する架空の企業で、Auth0 テナントを設定しています。Travel0 には複数のアプリケーションがありますが、ここでは 組織 を使用することでメリットが得られる 1 つのアプリケーションに注目します。 Travel0 Adventure Management: 顧客が急流ラフティング、乗馬、ジップラインなどのアドベンチャーを作成して販売できるオンラインアプリケーションです。各アドベンチャーにはガイドが付き、ガイドはこのアプリケーションを使って登録やスケジュール管理を行えます。ガイドは顧客に直接雇用されている場合もあれば、フリーランスの場合もあります。 このアプリケーションの顧客には、次のような企業があります。
  • Granite Outpost Rafting and Ziplines: 多数のガイドを直接雇用している老舗企業ですが、必要に応じてフリーランスのガイドにも依頼しています。従業員向けに独自の を利用しています。
  • AdventureZ: 多数のガイドを直接雇用している大規模なイベント会社ですが、頻度は低いもののフリーランスも利用しています。また、ガイドを必要としている他社向けに、自社の従業員がフリーランスとして働けるようにしています。従業員向けに独自の IdP を利用しています。
  • Rocky Mountain High Adventures: 市場に参入したばかりの新しい会社です。共同創業者がツアーの大半を運営し、繁忙期にはフリーランスに支援を依頼しています。IT スタッフはおらず、独自の ID プロバイダー (IdP) を設定する時間もなければ、その意向もありません。AdventureZ と契約しており、AdventureZ の従業員であれば誰でも同社向けにフリーランスとして働けます。

​
計画時の考慮事項

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

​
ログイン体験

まず、ユーザーが組織にログインする際に、どのような体験にするかを決める必要があります。エンドユーザーを Auth0 の特定の組織のログインプロンプトに直接送ることも、ログイン先の組織名を入力できるプロンプトに送ることもできます。 また、アプリケーション用に設定されたデフォルトの ページを使用するか、ページテンプレートを使用して各組織専用のログインページをカスタマイズするかを選択する必要があります。詳細については、最初の組織を作成する を参照してください。

​
接続モデル

通常、各組織はビジネス上の顧客またはパートナーのいずれか1つに直接対応しますが、ユーザーは複数の組織のメンバーになることもできます。ユーザーと顧客組織の対応関係を理解することで、組織と接続をどのようにモデル化すべきか判断しやすくなります。ユーザーのシナリオは 2 つあります。
  • ユーザーが組織ごとに分離される: すべてのユーザーは、必ず 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 組織にメンバーシップを割り当てる必要があります。
組織の数と接続モデルの構成を決定したら、データベース、ソーシャル、または エンタープライズ 接続を設定し、組織を作成 し、組織メンバーシップを設定 または 組織の接続を有効化 できます。

​
ロール

組織のメンバーには、ロールを割り当てることができます。これらのロールを使用して、アプリケーションのアクセス制御を定義できます。たとえば、Auth0 の API や SDK を使用してユーザー向けのダッシュボードを構築した場合は、特定のメンバーに管理者ロールを割り当て、そのダッシュボードから自分の組織を管理できるようにすることができます。
Management API へのアクセスには、機密クライアントのみを使用してください。その使用には、Auth0 Management API のレート制限が適用されます。

​
制限事項

Auth0 組織機能には、以下の制限があります。
  • この機能を利用できるかどうかは、Auth0 のサブスクリプションプランによって異なります。詳しくは、Auth0 Pricingを参照してください。
  • Universal Login でのみサポートされます (Classic Login または Lock.js ではサポートされません) 。
  • 組織 が有効なアプリケーションは、次のグラントおよびプロトコルと互換性がありません： Password、Device 、 (IdP としての Auth0) 。
  • 次はサポートされていません:
    • 組織ごとのカスタムドメイン (たとえば、このシナリオ例では、Rocky Mountain High Adventures と Granite Outpost Rafting and Ziplining の両方がログインドメインとして login.travel0.com を使用できるなら、組織 は有用です。一方で、Rocky Mountain High Adventures が login.rockymountain.com を、Granite Outpost が login.graniteoutpost.com を使用したい場合は、複数の Auth0 テナントを使用する必要があります。
    • Delegated Administration Extension との統合。
    • Authorization Extension との統合。
    • サードパーティアプリケーションとの統合。

​
詳細情報