你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

认证

项目
07/24/2024

进行 REST 调用时，需要执行几个步骤才能正确进行身份验证。 Azure 通信服务 SDK 为你处理此过程，但手动发出请求意味着需要自行处理它。

身份验证类型

Azure 通信服务有三种类型的身份验证，它们用于不同的用途：

用于短信、网络遍历、呼叫自动化、标识和访问令牌操作的访问密钥身份验证。访问密钥身份验证适用于在受信任的服务环境中运行的应用程序。
Azure RBAC 身份验证 通过分配 Azure 角色来控制对资源的访问。
聊天和通话的用户访问令牌身份验证。用户访问令牌允许客户端应用程序直接对 Azure 通信服务进行身份验证。这些令牌是在创建的服务器端令牌预配服务上生成的。然后，它们会提供给使用令牌初始化聊天和呼叫客户端库的客户端设备。

访问密钥身份验证

当最终用户应用程序未发出请求时，将使用访问密钥身份验证。在受信任的服务环境中运行这些请求。

在此身份验证方法中，使用客户端生成的基于哈希的消息身份验证代码（HMAC）对请求进行签名。

在开始之前，请确保具备：

Azure 通信服务访问密钥
Azure 通信服务终结点
要调用的 URL 路径和 HTTP 谓词
开发环境，可以生成 HMAC、SHA256 哈希和执行 Base64 操作。

获得这些项目后，可以继续对请求进行签名。

对 HTTP 请求进行签名

请确保具有以下可用值：
- HTTP 请求方法（例如，GET 或 PUT）
- 根据RFC1123标准对请求的协调世界时（UTC）时间戳
- HTTP 请求主机（RFC2396中指定的 <authority> URI 组件）
- 使用 SHA256 算法哈希处理 HTTP 请求正文
- HTTP 请求路径（由RFC2396中指定的 ? 组件连接 <path> 和 <query>）
```
Verb=<http_method>
Timestamp=<current_datetime>
Host=<uri_authority>
ContentHash=SHA256(<request_body>)
URIPathAndQuery=<uri_path>?<uri_query>
```

通过按以下方式连接值来构造要签名的字符串：

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

生成在上一步中创建的 UTF-8 编码字符串的 HMAC-256 签名。接下来，将结果编码为 Base64。还需要对访问密钥进行 Base64 解码。使用以下格式（显示为伪代码）：
```
Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_access_key>)))
```

将以下标头添加到请求：

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身份验证库）。下面是分步指南：

在 Azure AD 中注册应用程序：确保应用在 Azure AD 中注册。
安装 MSAL：为平台安装 MSAL 库（例如，适用于 .NET 的 Microsoft.Identity.Client）。
配置 MSAL：使用应用程序的客户端 ID、租户 ID 和客户端密码设置 MSAL。
获取令牌：使用 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 RBAC 上的有用链接

分配 Azure 角色的步骤。
使用 Azure 门户列出 Azure 角色分配。
将 Azure 角色分配管理委托给条件的其他人。
Azure 自定义角色。

用户访问令牌身份验证

用户访问令牌允许客户端应用程序以特定用户或标识的形式直接对 Azure 通信服务进行身份验证。

生成/获取用户访问令牌

用户访问令牌由你在受信任的环境中生成。使用 Azure 通信服务标识 SDK 生成它们是最简单的方法。有关详细信息，请参阅创建和管理用户访问令牌。

在请求中使用用户访问令牌

获得合适的用户访问令牌后，即可将其包含在对 Azure 通信服务的 REST API 的请求中。为此，需要使用 Bearer HTTP 身份验证方案 Authorization: Bearer <token>在 Authorization 标头中提供它。

另请参阅

有关 Azure 通信服务身份验证的其他信息，还可以查看：

对 HTTP 请求进行签名。
概念身份验证文档 - 提供有关如何使用 SDK 针对 REST API 进行身份验证的信息。
生成用户访问令牌服务 - Azure 通信服务教程，其中演示如何创建受信任的身份验证服务，以使用 Azure Functions 生成用户访问令牌。

通过

认证