次の方法で共有

ID モデル

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

  • Bring Your Own IDENTITY (BYOI) モデルを採用すると、ID 管理システムから既存の ID を再利用し、それらを Azure Communication Services ID にマップできます。
  • 既存の ID システムとうまく連携し、特定の ID プロバイダーに依存しません。
  • 名前などのユーザーのデータは、Azure Communication Services に複製する必要がないので、非公開のまま維持されます。
  • ID とアクセス管理に Microsoft Entra ID を使用する組織は、Entra ID ユーザーを使用して Azure Communication Services リソースに直接アクセスできるようになりました。 この Entra ID 認証の新しいサポートにより、独自の ID 管理または承認プロキシ サービスを開発または運用する必要がなくなります。 この機能は現在、パブリック プレビュー段階です。

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

Bring Your Own Identity (BYOI): ID 管理システムとの統合

Azure Communication Services では、Bring Your Own IDENTITY (BYOI) モデルがサポートされています。これにより、既存の ID 管理システムと統合できます。 Azure Communication Services でユーザー ID を作成し、独自のユーザー ID システムにマップできます。 この方法では、Azure Communication Services でユーザー データを複製することなく、ユーザー ID とアクセス トークンを管理できます。

次のセクションでは、Bring Your Own Identity (BYOI) モデルの主要な概念について説明します。

Bring Your Own IDENTITY (BYOI) モデルでのユーザー 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持ち込み（BYOI）モデルにおけるクライアント-サーバーアーキテクチャについて、マッピング設計を詳しく説明します。

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

Important

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

Note

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

以前は、開発者は、独自のユーザー 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 では、フル アクセスと制限付きアクセスを必要とするユーザーに対応するため、複数のトークン スコープがサポートされています。 アクセス トークンには次のプロパティがあります。

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

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

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

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

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

VoIP トークンのスコープ

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

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

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

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

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

Bring Your Own Identity (BYOI) モデルのクライアント/サーバー アーキテクチャ

クライアント アプリケーションでトークンを作成せず、信頼されたサービスを使用してユーザー アクセス トークンを作成および管理します。 ユーザー アクセス トークンを作成するには、接続文字列または 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 プロバイダーと統合されています。

Microsoft Entra ID: Entra ID との統合

Important

Azure Communication Services のこの機能は現在プレビュー中です。 プレビュー段階の機能は一般公開されており、新規および既存の Microsoft のすべてのお客様が使用できます。

プレビューAPIとSDKは、サービスレベル契約なしで提供されます。 運用環境のワークロードには使用しないことをお勧めします。 特定の機能がサポートされていないか、機能が制約されている可能性があります。

詳細については、「 Microsoft Azure プレビューの追加使用条件」を参照してください。

Azure Communication Services では Microsoft Entra ID 認証がサポートされるようになりました。これにより、Entra ID ユーザーを使用して Azure Communication Services リソースに直接アクセスできます。 この Entra ID 認証の新しいサポートにより、「 クライアント/サーバー アーキテクチャ」セクションで説明されている独自の ID 管理または承認プロキシ サービスを開発または運用する必要がなくなります。

次のセクションでは、Microsoft Entra ID 統合の重要な側面について説明します。

Microsoft Entra ID を使用してトークンにアクセスする

チャットや通話の機能など、Azure Communication Services の認証と承認では、Azure Communication Services のアクセス トークンのみがサポートされます。 トークンの構造と管理の詳細については、「 アクセス トークン」を参照してください。 Microsoft Entra ID パブリック プレビューでは、Entra ID 統合を通じて呼び出し (VoIP) アクセス トークン スコープのみがサポートされます。

Microsoft Entra ID 統合では、Entra ID を使用してユーザーを認証し、Azure Communication Services クライアント アプリケーションの API アクセス許可を持つ Entra ID ユーザー アクセス トークンを取得し、Azure Communication Services アクセス トークンと交換します。 Azure Communication Services Common SDK は、Entra ID ユーザー用の Azure Communication Services アクセス トークンを自動的に取得することで、シームレスな認証を提供します。 Azure Communication Services Common SDK を使用してロジックを実装する方法の詳細については、「Microsoft Entra ID ユーザーのアクセス トークンを取得する」を参照してください。

Azure Communication Services クライアント アプリケーションの API アクセス許可は、「チャット トークン スコープと VoIP トークン スコープ」セクションで説明されている Azure Communication Services アクセス トークン スコープ と一貫して名前 が付けられます。 次の表は、API のアクセス許可とアクセス トークン スコープの間のマッピングを示しています。

Important

チャット (メッセージング) API のアクセス許可 (Chat、 Chat.Join、 Chat.Join.Limited) は、パブリック プレビューの Microsoft Entra ID ではまだサポートされていません。 現時点では、VoIP 関連のアクセス許可 (VoIP、 VoIP.Join) のみが使用できます。 チャットのサポートは、今後の更新に向けて計画されています。

Azure Communication Services クライアント API のアクセス許可 Azure Communication Services アクセス トークンの適用範囲
Chat (Entra ID パブリック プレビュー: VoIP のみ - チャットの提供) chat
Chat.Join (Entra ID パブリック プレビュー: VoIP のみ - チャットの提供) chat.join
Chat.Join.Limited (Entra ID パブリック プレビュー: VoIP のみ - チャットの提供) chat.join.limited
VoIP voip
VoIP.Join voip.join

Azure Communication Services アクセス トークンは、Microsoft Entra ID ユーザー アクセス トークンと同じ有効期限で発行されます。

Microsoft Entra ID のクライアント アーキテクチャ

Microsoft Entra ID の統合により、認証と承認に Entra ID を直接使用してアーキテクチャを簡素化できます。 次の手順では、プロセスの概要を説明します。

Microsoft Entra ID 統合アーキテクチャを示す図。

  1. ユーザーがクライアント アプリケーションを起動します。
  2. クライアント アプリケーションは、Microsoft Entra ID を使用してユーザーを認証します。 クライアント アプリケーションは、Azure Communication Services クライアント アプリケーションの API アクセス許可を持つ Entra ID ユーザー アクセス トークンを取得します。
  3. クライアント アプリケーションは、次のいずれかの方法を使用して、Entra ID ユーザーの Azure Communication Services アクセス トークンを取得します。
    • Azure Communication Services Common SDK の使用: クライアントは、Entra ID トークン資格情報オプションを使用して CommunicationTokenCredential を初期化します。これは、Entra ID ユーザーの Azure Communication Services アクセス トークンの取得をバックグラウンドで自動的に処理します。 その後、アプリケーションはこの資格情報を使用して Azure Communication Services API にアクセスします。
    • カスタム実装: クライアント アプリケーションは、 Azure Communication Services アクセス トークン API の Exchange Entra ID トークン を呼び出して、Azure Communication Services アクセス トークンを取得します。 結果として得られる Azure Communication Services アクセス トークンは、Azure Communication Services API へのアクセスに使用されます。

このアーキテクチャでは、Microsoft Entra ID がユーザーの認証と承認を直接処理するため、個別の ID 管理サービスが不要になります。

制限事項

Microsoft Entra ID の統合は現在プレビュー段階であり、次の制限があります。

  • 継続的アクセス評価 は使用できません。 アクセス トークンをすぐに取り消すには、「 アクセス トークンの取り消し」の手順に従います。
  • Entra ID ユーザーを削除しても、関連付けられているすべてのデータが Communication Services リソースから自動的に削除されるわけではありません。 すべてのデータが確実に削除されるようにするには、「ID の 削除」の手順に従います。
  • チャット (メッセージング) API のアクセス許可 (Chat、 Chat.Join、 Chat.Join.Limited) は、パブリック プレビューでの Microsoft Entra ID 統合を介して付与または使用することはできません。 VoIP 関連のアクセス許可 (VoIP、 VoIP.Join) のみがサポートされています。 BYOI ID モデルを使用して、GA までチャット アクセス トークンを取得します。

次のステップ

  • Last updated on