身分識別模型

Azure 通訊服務是與身分識別無關的服務，可提供多個優點：

• 採用自備身分識別 （BYOI） 模型，可讓您從身分識別管理系統重複使用現有的身分識別，並將其對應至 Azure 通訊服務身分識別。
• 與任何現有的身分識別系統搭配運作良好，且與特定識別提供者沒有任何相依性。
• 保留用戶的數據，例如其名稱，私人，因為您不需要在 Azure 通訊服務 中複製它。
• 使用Microsoft Entra ID 進行身分識別和存取管理的組織現在可以直接使用 Entra ID 使用者存取 Azure 通訊服務資源。 此項新的 Entra ID 驗證支援，消除了開發或建置您自己的身分識別管理或授權代理服務的需求。 此功能目前為公開預覽狀態。

Azure 通訊服務身分識別模型搭配兩個主要概念運作。

自備身分識別 (BYOI)：與您的身分識別管理系統整合

Azure 通訊服務支援自備身分識別 （BYOI） 模型，可讓您與現有的身分識別管理系統整合。 您可以在 Azure 通訊服務中建立使用者身分識別，並將其對應至您自己的使用者身分識別系統。 這種方法可讓您管理使用者身分識別和存取令牌，而不需要複製 Azure 通訊服務中的用戶數據。

下列各節將引導您了解自攜身分識別（BYOI）模型的重要概念：

• 如何映射使用者身份：自攜身份識別模型中的使用者身份映射。
• 如何建立和管理存取權杖：存取權杖。
• 如何為身分識別管理實作用戶端-伺服器架構： 用於自備身分識別的用戶端伺服器架構（BYOI） 模型。

自備身分識別 (BYOI) 模型中的使用者身分識別對應

當您透過 SDK 或 REST API 建立使用者身分識別時，Azure 通訊服務 建立唯一的使用者識別碼。 您無法直接在 Azure 通訊服務中使用外部識別碼，例如電話號碼、使用者/裝置/應用程式識別碼或用戶名稱。 相反地，您必須使用通訊服務身分識別，並視需要維護與您自己的使用者標識碼系統的對應。

您可以免費建立 Azure 通訊服務使用者身分識別。 用戶只有在取用聊天或通話等通訊服務時，才會產生費用。 您如何使用產生的通訊服務身分識別，取決於您的案例。 例如，您可以對應身分識別 1:1、1:N、N:1 或 N:N，且您可以將其用於人類使用者或應用程式。 您的終端使用者可以同時使用多個裝置參與多個通訊會話。

管理 Azure 通訊服務 使用者身分識別與您自己的身分識別系統之間的對應是您作為開發人員的責任，而且不會內建。 例如，您可以在現有的用戶數據表中新增數據CommunicationServicesId行，以儲存相關聯的 Azure 通訊服務 身分識別。 在 自備身分識別（BYOI）模型的用戶端伺服器架構下，將更詳細描述映射設計。

(預覽) 使用 customId 簡化身分識別對應

先前，開發人員負責維護自己的使用者身分識別系統與 Azure 通訊服務身分識別之間的對應。 隨著引入 customId 參數，您現在可以在建立通訊服務身分識別時，直接關聯自己的使用者標識碼，例如電子郵件位址或內部使用者標識碼。

當您使用 customId 建立使用者時，如果您再次使用相同的 customId 呼叫該方法，Azure 通訊服務會傳回相同的身分識別。 這樣就不需要自行儲存和管理映射關係。

SDK 和 REST API 都支援這項功能，而且特別適用於您想要跨會話、裝置或服務維持一致身分識別，而不需要額外記憶體額外負荷的案例。

存取令牌

建立使用者身分識別之後，用戶接著需要具有特定範圍的存取令牌，才能使用聊天或通話參與通訊。 例如，只有具有chat範圍的令牌的使用者才能參與聊天。 只有具有 voip 範圍權杖的使用者，才能參與 VoIP 通話。

使用者可以同時擁有多個憑證。 Azure 通訊服務 支援多個令牌範圍，以考慮需要完整存取權與有限存取權的使用者。 存取權杖具有下列屬性。

存取權杖是 JSON Web 權杖 (JWT)，且具有完整性保護。 也就是說，無法在不使存取權杖失效的情況下變更其宣告，因為如此權杖簽章會不再相符。 如果通訊基本類型與無效的令牌搭配使用，則會拒絕存取。 雖然令牌未加密或模糊化，但您的應用程式不應該相依於令牌格式或其宣告。 令牌格式可以變更，且不屬於官方 API 合約的一部分。 Azure 通訊服務支援下列存取權杖範圍。

聊天權杖範圍

身分模型支援三種不同的聊天代碼範圍。 下表說明每個範圍的許可權。

• chat
• chat.join
• chat.join.limited

VoIP 權杖範圍

身分識別模型支援兩個 VoIP 權杖範圍。 下表說明每個範圍的許可權。

• voip
• voip.join

您可以將 voip.join 範圍與會議室搭配使用，以建立已排程的通話。 在此案例中，只有受邀的使用者可取得存取權，而且禁止使用者建立任何其他通話。

撤銷或更新存取權杖

• Azure 通訊服務身分識別程式庫可用於在到期時間之前撤銷存取權杖。 權杖撤銷不是立即完成。 可能需要長達 15 分鐘來傳播。
• 刪除身分識別、資源或訂用帳戶會撤銷所有存取令牌。
• 如果您想要移除使用者存取特定功能的能力，請撤銷使用者的所有存取令牌。 然後，發出範圍更有限的新存取權杖。
• 輪替存取金鑰會撤銷使用先前存取金鑰所建立的所有作用中存取權杖。 因此，所有身分識別都會失去 Azure 通訊服務的存取權，而且需要新的存取令牌。

自攜身分識別模型的客戶端-伺服器架構（BYOI）

透過受信任的服務建立和管理使用者存取令牌，而不是在用戶端應用程式中建立令牌。 您需要連接字串或Microsoft Entra 認證，才能建立使用者存取令牌。 請記得保護認證，將認證傳遞至用戶端可能會洩漏秘密。 當權杖被其他人員免費分配並誤用時，無法正確管理存取權杖可能會導致資源產生額外費用。

如果您快取存取權杖至備份存放區，建議您加密權杖。 存取令牌會提供敏感數據的存取權，而且若未受到保護，則可以用於惡意活動。 具有使用者存取令牌的任何人都可以存取該使用者的聊天數據，或參與模擬使用者的通話。

為了遵循最低許可權的安全性原則，請確保令牌中僅包含客戶端應用程式所需的範圍。

1. 使用者啟動用戶端應用程式。
2. 用戶端應用程式聯絡您的身分管理服務。
3. 身分識別管理服務會驗證應用程式使用者。 您可以略過使用者匿名的案例驗證，但接著請小心，將其他保護措施 (例如節流和 CORS) 新增至您的服務，以減輕權杖濫用。
4. 建立或尋找用戶的通訊服務身分識別。
   1. 穩定的身分識別案例： 您的身分識別管理服務會維護應用程式身分識別與通訊服務身分識別之間的對應。 （應用程式身分識別包括您的使用者和其他可尋址的物件，例如服務或機器人。）如果應用程式身分識別是新的，則會建立新的通訊身分識別，並儲存對應。
   2. 暫時身分識別案例： 身分識別管理服務會建立新的通訊身分識別。 在此案例中，相同的用戶最後會針對每個會話使用不同的通訊身分識別。
5. 身分識別管理服務會針對適用的身分識別發出使用者存取令牌，並將它傳回用戶端應用程式。

Azure 應用程式服務或 Azure Functions 是操作身分識別管理服務的兩種替代方案。 這些服務可以輕易地縮放，並具有對使用者進行驗證的內建功能。 它們與 OpenID 和 Facebook 等第三方身分識別提供者整合。

Microsoft Entra ID：與 Entra ID 整合

Azure 通訊服務現在支援 Microsoft Entra ID 驗證，可讓您直接與 Entra ID 使用者存取 Azure 通訊服務資源。 這項對 Entra ID 驗證的新支援，讓您無需開發或操作您自己的身分識別管理或授權 Proxy 服務，請參閱用戶端 -伺服器架構一節中所述。

下列各節將引導您了解 Microsoft Entra ID 整合的關鍵層面：

• 如何取得和管理存取權杖： 使用 Microsoft Entra ID 存取權杖。
• 如何使用 Microsoft Entra ID 實作用戶端架構： Microsoft Entra ID 的用戶端架構。
• 目前的限制和建議的指引： 限制。

使用 Microsoft Entra ID 的存取權杖

Azure 通訊服務中的驗證和授權僅支援 Azure 通訊服務存取權杖，包括聊天和通話功能。 如需權杖結構和管理的詳細資訊，請參閱 存取權杖。 在 Microsoft Entra ID 公開預覽期間，透過 Entra ID 整合僅支援通話（VoIP）存取權杖範圍。

透過 Microsoft Entra ID 整合，您可以透過 Entra ID 驗證使用者、取得具有 Azure 通訊服務用戶端應用程式 API 許可權的 Entra ID 使用者存取權杖，並將其交換為 Azure 通訊服務存取權杖。 Azure 通訊服務通用 SDK 會自動取得 Entra ID 使用者的 Azure 通訊服務存取權杖，以提供順暢的驗證。 如需如何使用 Azure 通訊服務通用 SDK 實作邏輯的詳細資訊，請參閱 取得 Microsoft Entra ID 使用者的存取權杖

Azure 通訊服務用戶端應用程式的 API 權限會與 聊天權杖範圍 和 VoIP 權杖範圍一節中所述的 Azure 通訊服務存取權杖範圍一致命名。 下表顯示 API 權限與存取權杖範圍之間的對應。

Azure 通訊服務存取權杖的發行期限與 Microsoft Entra ID 使用者存取權杖相同。

Microsoft Entra ID 的用戶端架構

透過 Microsoft Entra ID 整合，您可以直接使用 Entra ID 進行驗證和授權，以簡化架構。 以下步驟概述了該過程：

1. 使用者啟動用戶端應用程式。
2. 用戶端應用程式會透過 Microsoft Entra ID 驗證使用者。 用戶端應用程式會取得具有 Azure 通訊服務用戶端應用程式 API 許可權的 Entra ID 使用者存取權杖。
3. 用戶端應用程式會使用下列其中一種方法，取得 Entra ID 使用者的 Azure 通訊服務存取權杖：
   • 使用 Azure 通訊服務通用 SDK：用戶端會使用 Entra ID 權杖認證選項初始化 CommunicationTokenCredential ，這會自動在背景中處理取得 Entra ID 使用者的 Azure 通訊服務存取權杖。 然後，應用程式會使用此認證來存取 Azure 通訊服務 API。
   • 自訂實作：用戶端應用程式會呼叫 Azure 通訊服務存取權杖 API 的 Exchange Entra ID 權杖 ，以取得 Azure 通訊服務存取權杖。 然後，產生的 Azure 通訊服務存取權杖會用來存取 Azure 通訊服務 API。

此架構不需要個別的身分識別管理服務，因為 Microsoft Entra ID 會直接處理使用者驗證和授權。

局限性

Microsoft Entra ID 整合目前處於預覽階段，並具有下列限制：

• 無法使用持續存取評估 。 若要立即撤銷存取權杖，請遵循 撤銷存取權杖中的指示。
• 移除 Entra ID 使用者不會自動從通訊服務資源移除所有相關聯的資料。 若要確保刪除所有資料，請遵循 刪除身分中的指示。
• 聊天 （傳訊） API 權限 （Chat， Chat.Join， Chat.Join.Limited） 無法透過公開預覽版中的 Microsoft Entra ID 整合授與或使用。 僅支援 VoIP 相關權限 （VoIP， VoIP.Join）。 使用 BYOI 身分模型來取得聊天存取權杖，直到 GA 為止。

後續步驟

• 若要發出令牌，請參閱 建立和管理終端使用者的存取令牌。
• 如需驗證的簡介，請參閱向 Azure 通訊服務驗證。
• 如需了解驗證在單一租戶和多租戶 Microsoft Entra ID 案例中運作方式的詳細資訊，請參閱 Microsoft Entra ID 中的租用。
• 如需如何驗證 Microsoft Entra ID 使用者的快速入門，請參閱 驗證 Microsoft Entra ID 使用者。
• 若要閱讀數據落地和隱私權的相關信息，請參閱 區域可用性和數據落地。
• 如需簡單身分識別管理服務的完整範例，請參閱 信任的服務教學課程。
• 如需與 Entra ID 和 Microsoft Graph 整合的更進階身分識別管理範例，請參閱 驗證服務主圖範例。