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 によって一意のユーザー識別子が作成されます。 電話番号や、ユーザー、デバイス、アプリケーションの ID や、ユーザー名といった外部の識別子を、Azure Communication Services で直接使うことはできません。 代わりに、Communication Services の ID を使い、必要に応じてお客様独自のユーザー ID システムへのマッピングを維持する必要があります。 Azure Communication Services のユーザー ID の作成は無料であり、ユーザーがチャットや通話などの通信モダリティを使った場合にのみ課金されます。 生成された Communication Services ID の使い方は、シナリオによって異なります。 たとえば、ID を 1:1、1:N、N:1、または N:N でマップでき、それを人間のユーザーまたはアプリケーションに使用できます。 ユーザーは、複数のデバイスを使って、複数の通信セッションに同時に参加できます。 Azure Communication Services のユーザー ID と独自の ID システムの間のマッピングの管理は開発者の責任であり、組み込まれてはいません。 たとえば、既存のユーザー テーブルに CommunicationServicesId 列を追加して、関連付けられている Azure Communication Services の ID を格納できます。 マッピングの設計について詳しくは、「クライアント/サーバー アーキテクチャ」をご覧ください。
アクセス トークン
ユーザー ID が作成された後、ユーザーがチャットまたは通話を使って通信に参加するには、特定のスコープを持つアクセス トークンが必要です。 たとえば、チャットに参加できるのは chat スコープのトークンを持つユーザーのみであり、VoIP 通話に参加できるのは voip スコープのトークンを持つユーザーだけです。 ユーザーは複数のトークンを同時に持つことができます。 Azure Communication Services では、フル アクセスと制限付きアクセスを必要とするユーザーに対応するため、複数のトークン スコープがサポートされています。 アクセス トークンには次のプロパティがあります。
| プロパティ | 説明 |
|---|---|
| サブジェクト | トークンによって表されるユーザー ID。 |
| [有効期限] | アクセス トークンの有効期間は 1 時間以上、24 時間以下です。 有効期限が切れると、アクセス トークンは無効になり、サービスへのアクセスに使用できなくなります。 カスタム有効期限を持つトークンを作成するには、必要な有効期間を分単位で指定します (>= 60、< 1440)。 トークンの既定の有効期間は 24 時間です。 1 回限りの会議には有効期間が短いトークンを使い、アプリケーションを長時間使うユーザーには有効期間が長いトークンを使うことをお勧めします。 |
| スコープ | スコープでは、トークンを使ってアクセスできる通信プリミティブ (チャット/VoIP) が定義されています。 |
アクセス トークンは JSON Web Token (JWT) であり、整合性が保護されています。 つまり、要求を変更するとトークン署名が一致しなくなるため、アクセス トークンを無効にしないで要求を変更することはできません。 無効なトークンで通信プリミティブを使った場合、アクセスは拒否されます。 トークンは暗号化または難読化されていませんが、アプリケーションではトークンの形式またはその要求に依存しないようにする必要があります。 トークンの形式は変更される可能性があり、公式の API コントラクトの一部ではありません。 Azure Communication Services により、アクセス トークンに対して次のスコープがサポートされます。
チャット トークンのスコープ
チャット トークンでは 3 つの異なるスコープがサポートされています。 次の表は各スコープのアクセス許可の説明です。
chatchat.joinchat.join.limited
| 機能/トークンのスコープ | chat | chat.join | chat.join.limited |
|---|---|---|---|
| チャット スレッドを作成する | 年 | N | N |
| ID を指定してチャット スレッドを更新する | 年 | N | N |
| ID を指定してチャット スレッドを削除する | 年 | N | N |
| チャット スレッドに参加者を追加する | 年 | 対応 | N |
| チャット スレッドから参加者を削除する | 年 | 対応 | N |
| チャット スレッドを取得する | 年 | 対応 | Y |
| ID を指定してチャット スレッドを取得する | 年 | 対応 | Y |
| ReadReceipt を取得する | 年 | 対応 | Y |
| ReadReceipt を作成する | 年 | 対応 | Y |
| ID を指定してチャット スレッドのメッセージを作成する | 年 | 対応 | Y |
| メッセージ ID を指定してメッセージを取得する | 年 | 対応 | Y |
| メッセージ ID を指定して独自のメッセージを更新する | 年 | 対応 | Y |
| メッセージ ID を指定して独自のメッセージを削除する | 年 | 対応 | Y |
| 入力インジケーターの送信 | 年 | 対応 | Y |
| スレッド ID の参加者を取得する | 年 | 対応 | Y |
VoIP トークンのスコープ
VoIP トークンでは 2 つのスコープがサポートされています。 次の表は各スコープのアクセス許可の説明です。
voipvoip.join
| 機能/トークンのスコープ | voip | voip.join |
|---|---|---|
| VoIP 通話を始める | 年 | N |
| ユーザーが既に会議室に招待されているときに、Virtual Rooms で VoIP 通話を始める | 年 | Y |
| 進行中の VoIP 通話に参加する | 年 | Y |
| ユーザーが既に会議室に招待されているときに、Virtual Rooms で進行中の VoIP 通話に参加する | 年 | Y |
| ミュートとミュート解除、画面共有など、他のすべての通話中操作 | 年 | Y |
| ミュートとミュート解除、画面共有など、Virtual Rooms での他のすべての通話中操作 | ユーザー ロールによって決定されます | ユーザー ロールによって決定されます |
voip.join スコープを Rooms と共に使って、招待されたユーザーのみがアクセスでき、ユーザーは他の通話を作成できない、スケジュールされた通話を作成できます。
アクセス トークンの取り消しまたは更新
- Azure Communication Services の ID ライブラリを使って、有効期限前にアクセス トークンを取り消すことができます。 トークンの失効はすぐにはできません。 伝達されるまでに最大 15 分かかる場合があります。
- ID、リソース、またはサブスクリプションを削除すると、すべてのアクセス トークンが取り消されます。
- 特定の機能にユーザーがアクセスできないようにする場合は、ユーザーに対するアクセス トークンをすべて取り消します。 次に、スコープ セットがより制限された新しいアクセス トークンを発行します。
- アクセス キーをローテーションすると、以前のアクセス キーを使って作成されたすべてのアクティブなアクセス トークンが取り消されます。 したがって、すべての ID が Azure Communication Services にアクセスできなくなり、新しいアクセス トークンが必要になります。
クライアント/サーバー アーキテクチャ
ユーザー アクセス トークンは、クライアント アプリケーションでは作成せず、信頼されたサービスを使って作成と管理を行う必要があります。 ユーザー アクセス トークンの作成に必要な接続文字列または Microsoft Entra 資格情報は、保護する必要があります。それをクライアントに渡すと、シークレットが漏洩する恐れがあります。 アクセス トークンを適切に管理しないと、トークンが自由に配布され、他のユーザーによって悪用されて、リソースに追加料金が発生する可能性があります。
アクセス トークンをバッキング ストアにキャッシュする場合は、トークンを暗号化することをお勧めします。 アクセス トークンを使うと機密データにアクセスできるので、保護しないと悪意のあるアクティビティに使われる可能性があります。 あるユーザーのアクセス トークンを持つ全員が、そのユーザーのチャット データにアクセスしたり、そのユーザーを偽装して通話に参加したりできます。
最小限の特権のセキュリティ原則に従うため、クライアント アプリケーションで必要なスコープのみをトークンに含めるようにしてください。
- ユーザーがクライアント アプリケーションを起動します。
- クライアント アプリケーションが、ID 管理サービスに接続します。
- ID 管理サービスが、アプリケーション ユーザーの認証を行います。 ユーザーが匿名のシナリオでは認証を省略できますが、その場合は、トークンの不正使用を軽減するため、スロットリングや CORS などの他の保護対策をサービスに追加するように注意してください。
- ユーザーの Communication Services ID を作成または検索します。
- "安定した ID のシナリオ": お使いの ID 管理サービスが、アプリケーション ID と Communication Services ID の間のマッピングを維持します。 (アプリケーション ID には、ユーザーと、サービスやボットなどのアドレス指定可能な他のオブジェクトが含まれます。)アプリケーション ID が新しい場合は、新しい Communication ID が作成されて、マッピングが格納されます。
- "一時的な ID のシナリオ": ID 管理サービスによって新しい Communication ID が作成されます。 このシナリオでは、同じユーザーでもセッションごとに異なる Communication ID になります。
- ID 管理サービスが該当する ID に対するユーザー アクセス トークンを発行し、それをクライアント アプリケーションに返します。
Azure App Service と Azure Functions の 2 つが、ID 管理サービスを運用するための選択肢になります。 これらのサービスはスケーリングが簡単で、ユーザーを 認証 するための機能が組み込まれています。 これらは、 OpenID や、 Facebookのようなサードパーティ ID プロバイダーと統合されています。
次のステップ
- トークンの発行方法については、「アクセス トークンの作成と管理」をご覧ください。
- 認証の概要については、「Azure Communication Services に対する認証」を参照してください。
- データ所在地とプライバシーについては、「利用可能なリージョンとデータの保存場所」をご覧ください。
- テストのために ID とトークンをすばやく作成する方法については、ID のすばやい作成のクイックスタートに関する記事をご覧ください。
- 簡単な ID 管理サービスの完全なサンプルについては、信頼されたサービスのチュートリアルに関する記事をご覧ください。
- Entra ID および Microsoft Graph と統合する、より高度な ID 管理のサンプルについては、認証サービスのヒーロー サンプルに関する記事をご覧ください。