共用方式為

認證

  • 發行項

進行 REST 呼叫時，需要數個步驟才能正確驗證。 Azure 通訊服務 SDK 會為您處理此程式，但手動提出要求表示您必須自行處理。

驗證類型

Azure 通訊服務有三種類型的驗證，用於不同的用途：

  • SMS、網路周遊、通話自動化、身分識別和存取令牌作業的存取密鑰驗證。 存取金鑰驗證適用於在受信任服務環境中執行的應用程式。
  • Azure RBAC 驗證，藉由指派 Azure 角色，利用 Azure RBAC 來控制資源的存取。
  • 聊天和通話的使用者存取令牌驗證。 使用者存取令牌可讓您的用戶端應用程式直接向 Azure 通訊服務進行驗證。 這些令牌會在您建立的伺服器端令牌布建服務上產生。 然後會提供給使用令牌來初始化聊天和通話客戶端連結庫的客戶端裝置。

存取金鑰驗證

當您的使用者應用程式未提出要求時，會使用存取金鑰驗證。 在受信任的服務環境中執行這些要求。

在此驗證方法中，要求會使用用戶端產生的 哈希式訊息驗證碼（HMAC）簽署。

開始之前，請確定您有：

  • 您的 Azure 通訊服務存取金鑰
  • 您的 Azure 通訊服務端點
  • 您要呼叫的 URL 路徑和 HTTP 動詞
  • 開發環境，可產生 HMAC、SHA256 哈希，以及執行 Base64 作業。

擁有這些項目之後，您就可以繼續簽署您的要求。

簽署 HTTP 要求

  1. 請確定您有下列可用值：

    • HTTP 要求方法（例如，GET 或 PUT）
    • 根據RFC1123標準，要求的國際標準時間 （UTC） 時間戳
    • HTTP 要求主機（RFC2396中指定的 <authority> URI 元件）
    • 使用 SHA256 演算法哈希的 HTTP 要求本文
    • HTTP 要求路徑（<path> 和 <query> 由 ? 元件串連，如RFC2396中所指定）
    Verb=<http_method>
Timestamp=<current_datetime>
Host=<uri_authority>
ContentHash=SHA256(<request_body>)
URIPathAndQuery=<uri_path>?<uri_query>

  2. 以下列方式串連值來建構要簽署的字串：

    StringToSign=Verb + "\n"
URIPathAndQuery + "\n"
Timestamp + ";" + Host + ";" + ContentHash

  3. 產生您在上一個步驟中建立之 UTF-8 編碼字串的 HMAC-256 簽章。 接下來，將您的結果編碼為Base64。 您也需要將存取金鑰譯碼為Base64。 使用下列格式（如虛擬程式碼所示）：

    Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_access_key>)))

  4. 將下列標頭新增至要求：

    x-ms-date: <Timestamp>
x-ms-content-sha256: <ContentHash>
host: <URIPathAndQuery>   
Authorization: "HMAC-SHA256 SignedHeaders=x-ms-date;host;x-ms-content-sha256&Signature=<Signature>"

收到要求后，服務會驗證簽章和時間戳，以防範某些安全性攻擊，包括重新執行攻擊。 若要瞭解如何以各種程式設計語言簽署 HTTP 要求，請瀏覽 HMAC 標頭簽署教學課程。

Azure RBAC 驗證

Azure 平臺提供角色型存取 （Azure RBAC） 來控制資源的存取。 Azure RBAC 安全性主體代表要求存取 Azure 資源的使用者、群組、服務主體或受控識別。

Microsoft Entra 驗證提供優於其他授權選項的安全性和易於使用。 例如，藉由使用受控識別，您可以避免在程式代碼中儲存帳戶存取密鑰，就像使用存取密鑰驗證一樣。 雖然您可以繼續使用存取密鑰驗證與通訊服務應用程式，但Microsoft建議您盡可能移至Microsoft Entra ID。

Azure RBAC 包含許多內建角色，可在不同的範圍指派，並可讓您建立自己的自定義角色。 其中包含超過 100 個內建角色。 有五個基本 Azure 角色 - 擁有者、參與者、讀者、角色型訪問控制管理員和使用者存取管理員。 如需這些角色的詳細資訊，請瀏覽 角色型存取控制教學課程。

Azure 通訊服務支持的許可權 （ACS）

ACS 提供特定許可權（acs.read 和 acs.write），允許控制對各種資源的存取。

  • acs.read 許可權：授與擷取或檢視數據的能力。
  • acs.write 許可權：允許修改或建立這些相同資源類型內的數據。

此外，ACS 支援電子郵件相關許可權：

  • acs.email.read：啟用讀取或存取電子郵件相關服務數據。
  • acs.email.write：允許修改或建立與電子郵件相關的服務數據。

這些許可權對於確保 ACS 資源的細微存取控制和安全性至關重要。

取得其他 RBAC 令牌

若要取得 ACS 的權杖，您可以使用 MSAL （Microsoft 驗證連結庫）。 以下是逐步指南：

  1. 在 Azure AD 中註冊應用程式：確定您的應用程式已在 Azure AD 中註冊。
  2. 安裝 MSAL：安裝適用於您平臺的 MSAL 連結庫（例如，適用於 .NET 的 Microsoft.Identity.Client）。
  3. 設定 MSAL：使用應用程式的用戶端標識碼、租使用者識別碼和用戶端密碼來設定 MSAL。
  4. 取得令牌：使用 MSAL 取得具有必要範圍 （https://communication.azure.com/.default） 的令牌。

如需詳細指示和程式代碼範例，請參閱 官方 MSAL 檔 和 存取令牌檔。

發出 ACS 存取令牌的 HTTP 要求範例

要求：

POST https://my-resource.communication.azure.com/identities/{identity}/:issueAccessToken?api-version=2023-10-01
Authorization: Bearer <your-access-token>
Content-Type: application/json
{
  "scopes": [
    "chat",
    "voip"
  ]
}

回應：

{
  "token": "token",
  "expiresOn": "2023-10-10T21:39:39.3244584+00:00"
}

使用者存取令牌驗證

使用者存取令牌可讓您的用戶端應用程式以特定的使用者或身分識別，直接向 Azure 通訊服務進行驗證。

產生/取得使用者存取令牌

使用者存取令牌是由您在信任的環境中產生的。 使用 Azure 通訊服務身分識別 SDK 產生它們是最簡單的方式。 如需詳細資訊，請參閱 建立和管理使用者存取令牌。

在要求中使用使用者存取令牌

擁有適當的使用者存取令牌之後，您可以將它包含在對 Azure 通訊服務的 REST API 要求中。 若要這樣做，您必須使用持有人 HTTP 驗證配置 Authorization: Bearer <token>，在 Authorization 標頭內提供它。

另請參閱

如需 Azure 通訊服務驗證的其他資訊，您也可以檢閱：