次の方法で共有

ID モデル

Azure Communication Services は ID に依存しないサービスであり、それにはいくつかの利点があります。

  • お使いの ID 管理システムの既存の ID を再利用し、それらを Azure Communication Services の ID にマップします。
  • 既存の ID システムとうまく連携し、特定の ID プロバイダーに依存しません。
  • 名前などのユーザーのデータは、Azure Communication Services に複製する必要がないので、非公開のまま維持されます。

Azure Communication Services の ID モデルは、2 つの主要な概念を使って機能します。

ユーザー ID とマッピング

SDK または REST API を使ってユーザー ID を作成すると、Azure Communication Services によって一意のユーザー識別子が作成されます。 Azure Communication Services では、電話番号、ユーザー/デバイス/アプリケーション ID、ユーザー名などの外部識別子を直接使用することはできません。 代わりに、Communication Services ID を使用し、必要に応じて独自のユーザー ID システムへのマッピングを維持する必要があります。

Azure Communication Service ユーザー ID は無料で作成できます。 ユーザーがチャットや通話などの通信サービスを使用する場合は、料金のみが発生します。 生成された Communication Services ID の使い方は、シナリオによって異なります。 たとえば、ID を 1:1、1:N、N:1、または N:N でマップでき、それを人間のユーザーまたはアプリケーションに使用できます。 エンド ユーザーは、複数のデバイスを使用して複数の通信セッションに同時に参加できます。

Azure Communication Services のユーザー ID と独自の ID システムの間のマッピングの管理は開発者の責任であり、組み込まれてはいません。 たとえば、既存のユーザー テーブルに CommunicationServicesId 列を追加して、関連付けられている Azure Communication Services の ID を格納できます。 マッピングの設計について詳しくは、「クライアント/サーバー アーキテクチャ」をご覧ください。

(プレビュー)を使用して ID マッピングを簡略化する customId

Von Bedeutung

この機能は、Identity SDK バージョンの 1.4.0-beta1 と REST API バージョン 2025-03-02-preview以降で使用できます。

注

この機能は現在プレビュー段階です。

以前は、開発者は、独自のユーザー ID システムと Azure Communication Services ID の間のマッピングを維持する役割を担っていました。 customId パラメーターの導入により、Communication Services ID を作成するときに、電子メール アドレスや内部ユーザー ID などの独自のユーザー ID を直接関連付けることができるようになりました。

customIdを使用してユーザーを作成すると、同じcustomIdでメソッドを再度呼び出すと、Azure Communication Services は同じ ID を返します。 これにより、マッピングを自分で格納および管理する必要がなくなります。

この機能は SDK と REST API の両方でサポートされており、追加のストレージ オーバーヘッドなしでセッション、デバイス、またはサービス間で一貫した ID を維持する必要があるシナリオに特に役立ちます。

アクセス トークン

ユーザー ID を作成した後、エンド ユーザーはチャットまたは通話を使用して通信に参加するために、特定のスコープを持つアクセス トークンを必要とします。 たとえば、 chat スコープのトークンを持つユーザーのみがチャットに参加できます。 スコープ voip トークンを持つユーザーのみが VoIP 呼び出しに参加できます。

ユーザーは複数のトークンを同時に持つことができます。 Azure Communication Services では、フル アクセスと制限付きアクセスを必要とするユーザーに対応するため、複数のトークン スコープがサポートされています。 アクセス トークンには次のプロパティがあります。

プロパティ 説明
サブジェクト トークンによって表されるユーザー ID。
[有効期限] アクセス トークンの有効期間は 1 時間以上、24 時間以下です。 有効期限が切れると、アクセス トークンは無効になり、サービスへのアクセスに使用できなくなります。 カスタム有効期限を持つトークンを作成するには、必要な有効期間を分単位で指定します (>= 60、< 1440)。 トークンの既定の有効期間は 24 時間です。 アプリケーションを長期間必要とするユーザーには、単一の会議に短い有効期間トークンを使用し、有効期間が長いトークンを使用することをお勧めします。
スコープ スコープは、トークンを使用してアクセスできるサービス (Chat/VoIP) を定義します。

アクセス トークンは JSON Web Token (JWT) であり、整合性が保護されています。 つまり、要求を変更するとトークン署名が一致しなくなるため、アクセス トークンを無効にしないで要求を変更することはできません。 無効なトークンで通信プリミティブを使った場合、アクセスは拒否されます。 トークンは暗号化または難読化されていませんが、アプリケーションではトークンの形式またはその要求に依存しないようにする必要があります。 トークンの形式は変更される可能性があり、公式の API コントラクトの一部ではありません。 Azure Communication Services により、アクセス トークンに対して次のスコープがサポートされます。

チャット トークンのスコープ

ID モデルでは、3 つの異なるチャット トークン スコープがサポートされています。 次の表は各スコープのアクセス許可の説明です。

  • chat
  • chat.join
  • chat.join.limited
機能/トークンのスコープ chat chat.join chat.join.limited
チャット スレッドを作成する 対応 非対応 非対応
ID を指定してチャット スレッドを更新する 対応 非対応 非対応
ID を指定してチャット スレッドを削除する 対応 非対応 非対応
チャット スレッドに参加者を追加する 対応 対応 非対応
チャット スレッドから参加者を削除する 対応 対応 非対応
チャット スレッドを取得する 対応 対応 対応
ID を指定してチャット スレッドを取得する 対応 対応 対応
ReadReceipt を取得する 対応 対応 対応
ReadReceipt を作成する 対応 対応 対応
ID を指定してチャット スレッドのメッセージを作成する 対応 対応 対応
メッセージ ID を指定してメッセージを取得する 対応 対応 対応
メッセージ ID を指定して独自のメッセージを更新する 対応 対応 対応
メッセージ ID を指定して独自のメッセージを削除する 対応 対応 対応
入力インジケーターの送信 対応 対応 対応
スレッド ID の参加者を取得する 対応 対応 対応

VoIP トークンのスコープ

ID モデルでは、2 つの VoIP トークン スコープがサポートされています。 次の表は各スコープのアクセス許可の説明です。

  • voip
  • voip.join
機能/トークンのスコープ voip voip.join
VoIP 通話を始める 対応 非対応
ユーザーが既に会議室に招待されているときに、Virtual Rooms で VoIP 通話を始める 対応 対応
進行中の VoIP 通話に参加する 対応 対応
ユーザーが既に会議室に招待されているときに、Virtual Rooms で進行中の VoIP 通話に参加する 対応 対応
ミュート/ミュート解除、画面共有など、他のすべての通話中操作 対応 対応
Virtual Rooms でのミュート/ミュート解除、画面共有などの他のすべての通話中操作 ユーザー ロールによって決定されます ユーザー ロールによって決定されます

voip.joinスコープを Rooms と共に使用して、スケジュールされた通話を作成できます。 このシナリオでは、招待されたユーザーのみがアクセスでき、ユーザーは他の通話を作成できません。

アクセス トークンの取り消しまたは更新

  • Azure Communication Services の ID ライブラリを使って、有効期限前にアクセス トークンを取り消すことができます。 トークンの失効はすぐにはできません。 伝達されるまでに最大 15 分かかる場合があります。
  • ID、リソース、またはサブスクリプションを削除すると、すべてのアクセス トークンが取り消されます。
  • 特定の機能にユーザーがアクセスできないようにする場合は、ユーザーに対するアクセス トークンをすべて取り消します。 次に、スコープ セットがより制限された新しいアクセス トークンを発行します。
  • アクセス キーをローテーションすると、以前のアクセス キーを使って作成されたすべてのアクティブなアクセス トークンが取り消されます。 そのため、すべての ID が Azure Communication Services へのアクセスを失い、新しいアクセス トークンが必要になります。

クライアント/サーバー アーキテクチャ

クライアント アプリケーションでトークンを作成せず、信頼されたサービスを使用してユーザー アクセス トークンを作成および管理します。 ユーザー アクセス トークンを作成するには、接続文字列または Microsoft Entra 資格情報が必要です。 資格情報を保護することを忘れないでください。資格情報をクライアントに渡すと、シークレットが漏洩するリスクがあります。 アクセス トークンを適切に管理しないと、トークンが自由に分配され、他のユーザーによって悪用された場合、リソースに追加料金が発生する可能性があります。

アクセス トークンをバッキング ストアにキャッシュする場合は、トークンを暗号化することをお勧めします。 アクセス トークンを使うと機密データにアクセスできるので、保護しないと悪意のあるアクティビティに使われる可能性があります。 あるユーザーのアクセス トークンを持つ全員が、そのユーザーのチャット データにアクセスしたり、そのユーザーを偽装して通話に参加したりできます。

最小限の特権のセキュリティ原則に従うため、クライアント アプリケーションで必要なスコープのみをトークンに含めるようにしてください。

ユーザー アクセス トークンのアーキテクチャを示す図。

  1. ユーザーがクライアント アプリケーションを起動します。
  2. クライアント アプリケーションが、ID 管理サービスに接続します。
  3. ID 管理サービスが、アプリケーション ユーザーの認証を行います。 ユーザーが匿名のシナリオでは認証を省略できますが、その場合は、トークンの不正使用を軽減するため、スロットリングや CORS などの他の保護対策をサービスに追加するように注意してください。
  4. ユーザーの Communication Services ID を作成または検索します。
    1. "安定した ID のシナリオ": お使いの ID 管理サービスが、アプリケーション ID と Communication Services ID の間のマッピングを維持します。 (アプリケーション ID には、ユーザーと、サービスやボットなどのアドレス指定可能な他のオブジェクトが含まれます。)アプリケーション ID が新しい場合は、新しい Communication ID が作成されて、マッピングが格納されます。
    2. "一時的な ID のシナリオ": ID 管理サービスによって新しい Communication ID が作成されます。 このシナリオでは、同じユーザーでもセッションごとに異なる Communication ID になります。
  5. ID 管理サービスが該当する ID に対するユーザー アクセス トークンを発行し、それをクライアント アプリケーションに返します。

Azure App Service と Azure Functions の 2 つが、ID 管理サービスを運用するための選択肢になります。 これらのサービスはスケーリングが簡単で、ユーザーを 認証 するための機能が組み込まれています。 これらは、 OpenID や、 Facebookのようなサードパーティ ID プロバイダーと統合されています。

次のステップ