メインコンテンツへスキップ
組織ベースのシナリオにおけるプロファイル管理は、通常、他のアーキテクチャシナリオの場合と同様です。Auth0 のアーキテクチャシナリオでは、ここで説明するガイダンスとあわせて確認することを推奨する、汎用的な B2B プロファイル管理 のガイダンスを提供しています。
ユーザーに関連付けられたロールを管理するには、まず Auth0 にユーザーアカウントが存在している必要があります。これは、Membership に関連付けられた Auth0 Organizations のロール機能を使用している場合でも同様です。ただし、ユーザー招待ワークフローを通じてプロビジョニングされたユーザーアカウントには、招待プロセスの一環として自動的にロールを割り当てることができます。詳しくは、組織メンバーを招待するを参照してください。別の方法でユーザーを事前登録する場合は、Role 情報を Auth0 の外部に保存し、初回認証時に拡張機能を使用して (たとえば Rule の一部として) アクセスまたはコピーする必要があります。
アプリケーションには、ユーザー向けに何らかのセルフサービス管理を提供する特定のユーザー属性セット (たとえば、ユーザー設定や、顧客により適したサービスを提供するために使用する識別情報) が関連付けられている場合があります。さらに、または代わりに、通常は (IdP) によって管理される属性について、セルフサービスのプロファイル管理を提供することもできます。
ベストプラクティス組織関連のシナリオでは、メールアドレスは常に確認済みである必要があります。そのため、他の方法でユーザーのメールアドレスを確認できない場合に備えて、セルフサービスのメールアドレス確認機能を提供する必要があります。詳細については、メールアドレス確認を参照してください。

​
データベース接続

Auth0 では、Auth0 の を使用して、セルフサービスによるプロファイル管理を実装できます。招待ベースのユーザープロビジョニング を提供するために Auth0 Organizations を使用している場合は、IDプロバイダー (IdP) として Auth0 テナントが通常管理するフィールドについて、変更を制限する必要が生じることがあります。たとえば、招待の送信先とは異なるメールアドレスをユーザーが使用できないようにするため、メールアドレスの変更を制限したい場合があります。メールアドレスフィールドの変更を制限すると、会社宛てのメールが、入力された個人用メールアドレスに送信されるのを防ぐことができます。 一方で、Auth0 のデータベース接続を介して認証するユーザーに対しては、いくつかのセルフサービス項目を提供することも検討できます。たとえば、ユーザーに次の操作を許可したい場合があります。
  • メールアドレスを変更する
  • 関連付けられた電話番号を変更する
  • ユーザー名を変更する
  • 規制遵守 (GDPR など) の一環としてアカウントを削除する
  • パスワード変更を行う。通常、これは パスワードリセット を通じて実装することを推奨しており、一般に ブランディング: パスワードリセットページ で説明されている組織固有のブランディングを利用します。
セルフサービス機能は通常、Auth0 の外部で実装およびホストする必要があり、高いセキュリティを確保しなければなりません。

​
Enterprise 接続

通常、接続先の IDプロバイダー (IdP) が IdP 管理のユーザープロフィール属性を扱うため、このユースケースではプロファイル管理はほとんど必要ありません。ただし、アプリケーション固有のユーザー属性を使用する場合は、セルフサービス機能を提供したいこともあります。 さらに、組織が Auth0 テナントからユーザーのプロビジョニングを解除できる手段を、ほぼ確実に提供する必要があります。Auth0 は、Auth0 の セッションの有効期限が切れた場合を除き、接続先の IdP とは通信しません。SSO セッションの有効期限までの時間は、ユーザーが削除されるほとんどのシナリオでは長すぎる可能性が高いため、組織の管理者には、ユーザーを個別にブロックまたは削除する手段が必要です。

​
ソーシャル接続

ソーシャル接続では、ユーザープロファイル管理は Enterprise 接続 の場合と同様のパターンに従いますが、上流の IdP は特定の組織ではなく、ソーシャルプロバイダーに関連付けられます。

​
管理

状況によっては、顧客に、その組織に関連付けられたユーザーアカウントを管理するためのアクセス権を付与したいことがあります。これは、ヘルプデスク担当者がユーザーに代わってユーザープロファイル情報を更新したり、アカウントのブロック解除を支援したりするような、ヘルプデスク向けのシナリオでよく見られます。 Auth0 には、Auth0 テナントの一般的な管理に使用する が標準で用意されています。ただし、顧客に Auth0 テナント Dashboard へのアクセス権を与えるべきではありません。そうすると、すべての組織にまたがるすべてのユーザーを管理できるようになってしまい、望ましくないためです。
Auth0 テナント Dashboard はユーザーアカウントの管理に使用できますが、組織レベルでの分離は提供されません。顧客に Auth0 Dashboard へのアクセス権を与えると、すべての組織にまたがるユーザーを変更できるようになってしまうため、望ましくありません。Auth0 Delegated Admin ダッシュボードは、Auth0 組織を考慮したユーザーアカウント管理を提供するように設定できます。ただし、ユーザーのメンバーシップや招待の管理には使用できません。
すでに顧客向けにヘルプデスク機能を提供している場合は、Auth0 Management API を使用して Auth0 のユーザーアカウントを管理できます。たとえば、Management API を使用して、組織メンバーの取得やユーザーが所属する組織の取得を行えます。まだヘルプデスク機能を提供していない場合は、必要に応じてこの機能を実装する必要があります。