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

使用 Azure Maps 进行身份验证

项目
10/19/2023

在 Azure Maps 中，有三种方式可以对请求进行身份验证，分别是：共享密钥身份验证、Microsoft Entra ID 身份验证和共享访问签名 (SAS) 令牌身份验证。本文介绍了身份验证方法，以帮助指导用户实现 Azure Maps 服务。本文还介绍了其他帐户控制，例如禁用 Azure Policy 的本地身份验证和跨域资源共享 (CORS)。

注意

为了改善与 Azure Maps 的安全通信，我们现在支持传输层安全性 (TLS) 1.2，并逐步停止支持 TLS 1.0 和 1.1。如果当前使用的是 TLS 1.x，请根据解决 TLS 1.0 问题中所述的测试，评估 TLS 1.2 就绪情况并制定合适的迁移计划。

共享密钥身份验证

有关在 Azure 门户中查看密钥的信息，请参阅查看身份验证详细信息。

创建了 Azure Maps 帐户后，将生成主密钥和辅助密钥。建议在通过共享密钥身份验证调用 Azure Maps 时，使用主密钥作为订阅密钥。共享密钥身份验证会将 Azure Maps 帐户生成的密钥传递到 Azure Maps 服务。对于发送到 Azure Maps 服务的每个请求，请将订阅密钥作为参数添加到 URL 中。辅助密钥可用于滚动密钥更改等方案中。

在 URL 中将订阅密钥用作参数的示例：

https://atlas.microsoft.com/mapData/upload?api-version=1.0&dataFormat=zip&subscription-key={Your-Azure-Maps-Subscription-key}

重要

应将主密钥和辅助密钥视为敏感数据。共享密钥可用于对所有 Azure Maps REST API 进行身份验证。使用共享密钥的用户应该通过环境变量或安全的机密存储将 API 密钥提取出来，以便集中进行管理。

Microsoft Entra 身份验证

Azure 订阅中自带 Microsoft Entra 租户，可实现精细的访问控制。 Azure Maps 支持使用 Azure AD 对 Microsoft Entra ID 服务进行身份验证。 Microsoft Entra 为 Microsoft Entra 租户中注册的用户和应用程序提供了基于身份的身份验证。

对于与包含 Azure Maps 帐户的 Azure 订阅相关联的 Microsoft Entra 租户，Azure Maps 接受 OAuth 2.0 访问令牌。 Azure Maps 还接受以下对象的令牌：

Microsoft Entra 用户
使用了用户委托权限的合作伙伴应用程序
Azure 资源的托管标识

Azure Maps 为每个 Azure Maps 帐户生成一个唯一的标识符（客户端 ID）。在将此客户端 ID 与其他参数结合使用时，可从 Microsoft Entra ID 请求令牌。

有关如何为 Azure Maps 配置 Microsoft Entra ID 和请求令牌的详细信息，请参阅在 Azure Maps 中管理身份验证。

有关使用 Microsoft Entra ID 进行身份验证的常规信息，请参阅身份验证与授权。

Azure 资源和 Azure Maps 的托管标识

Azure 资源的托管标识为 Azure 服务提供一个自动托管的基于应用程序的安全主体，该安全主体可通过 Microsoft Entra ID 进行身份验证。使用 Azure 基于角色的访问控制 (Azure RBAC)，可以授权托管标识安全主体访问 Azure Maps 服务。托管标识的一些示例包括：Azure 应用服务、Azure Functions 和 Azure 虚拟机。有关托管标识的列表，请参阅可以使用托管标识访问其他服务的 Azure 服务。有关托管标识的详细信息，请参阅使用 Azure Maps 管理身份验证。

配置应用程序 Microsoft Entra 身份验证

应用程序将使用 Microsoft Entra 提供的一个或多个受支持方案对 Microsoft Entra ID 租户进行身份验证。每个 Microsoft Entra 应用程序方案代表了不同业务需求下的不同要求。某些应用程序可能要求用户登录体验，还有一些应用程序可能要求应用程序登录体验。有关详细信息，请参阅身份验证流和应用程序方案。

在应用程序收到访问令牌后，SDK 和/或应用程序将发送 HTTPS 请求，其中包括以下一组必需的 HTTP 标头，以及其他 REST API HTTP 标头：

标头名称	值
x-ms-client-id	30d7cc…9f55
授权	Bearer eyJ0e…HNIVN

注意

x-ms-client-id 是 Azure Maps 身份验证页上显示的基于 Azure Maps 帐户的 GUID。

下面是使用 Microsoft Entra ID OAuth 持有者令牌的 Azure Maps 路由请求示例：

GET /route/directions/json?api-version=1.0&query=52.50931,13.42936:52.50274,13.43872
Host: atlas.microsoft.com
x-ms-client-id: 30d7cc….9f55
Authorization: Bearer eyJ0e…HNIVN

有关如何查看客户端 ID 的信息，请参阅查看身份验证详细信息。

提示

以编程方式获取客户端 ID

使用 PowerShell 时，客户端 ID 作为 UniqueId 属性存储在 IMapsAccount 中。使用 Get-AzMapsAccount 检索此属性，例如：

$maps = Get-AzMapsAccount -Name {Azure-Maps_Account-Name} -ResourceGroupName {Resource-Group-Name} -SubscriptionId {SubscriptionId}
$ClientId = $maps.UniqueId

使用 Azure CLI 时，请使用带有 --query 参数的 az maps account show 命令，例如：

$ClientId = az maps account show --name {Azure-Maps_Account-Name} --resource-group {Resource-Group-Name} --subscription {SubscriptionId} --query properties.uniqueId

使用基于角色的访问控制进行授权

先决条件

如果你不熟悉 Azure RBAC，Azure 基于角色的访问控制 (Azure RBAC) 概览介绍了“主体类型被授予了一组权限，也称为角色定义”。角色定义提供了对 REST API 操作的权限。 Azure Maps 支持访问 Azure 基于角色的访问控制 (Azure RBAC) 的所有主体类型，包括：各个 Microsoft Entra 用户、组、应用程序、Azure 资源和 Azure 托管标识。将访问权限应用到一个或多个 Azure Maps 帐户称为作用域。在应用主体、角色定义和作用域时，将创建角色分配。

概述

以下部分将讨论与 Azure Maps 与 Azure RBAC 集成的概念和组件。在设置 Azure Maps 帐户的过程中，Microsoft Entra 目录将关联到 Azure Maps 帐户所在的 Azure 订阅。

当配置 Azure RBAC 时，需选择一个安全主体并将其应用于角色分配。要了解如何在 Azure 门户上添加角色分配，请参阅使用 Azure 门户分配 Azure 角色。

选取角色定义

有下列角色定义类型支持应用程序方案。

Azure 角色定义	说明
Azure Maps 搜索和呈现数据读取者	仅提供对搜索和呈现 Azure Maps REST API 的访问权限，以限制对基本 Web 浏览器用例的访问。
Azure Maps 数据读取器	提供对不可变 Azure Maps REST API 的访问。
Azure Maps 数据参与者	提供对可变 Azure Maps REST API 的访问。可变性由写入和删除操作定义。
Azure Maps 数据读取和批处理角色	此角色可用于在 Azure Maps 上分配读取和批处理操作。
自定义角色定义	创建精心设计的角色，灵活限制对 Azure Maps REST API 的访问。

某些 Azure Maps 服务可能需要提升的权限才能对 Azure Maps REST API 执行写入或删除操作。对于提供写入或删除操作的服务，必须具有 Azure Maps 数据参与者角色。下表描述了在使用写入或删除操作时，Azure Maps 数据参与者适用于哪些服务。当只需要读取操作时，可以使用 Azure Maps 数据读取器角色来代替 Azure Maps 数据参与者角色。

Azure Maps 服务	Azure Maps 角色定义
Data	Azure Maps 数据参与者
创建者	Azure Maps 数据参与者
空间	Azure Maps 数据参与者
批量搜索和路由	Azure Maps 数据参与者

有关查看 Azure RBAC 设置的信息，请参阅如何为 Azure Maps 配置 Azure RBAC。

自定义角色定义

应用程序安全性的一个方面是最小特权原则，即将访问权限限制为当前作业所需的权限。限制访问权限是通过创建自定义角色定义来实现的，这些定义支持需要更细粒度的访问控制的用例。如果要创建自定义角色定义，请选择定义中要包含或排除的特定数据操作。

然后，即可在任何安全主体的角色分配中使用该自定义角色定义。如果要了解有关 Azure 自定义角色定义的详细信息，请参阅 Azure 自定义角色。

下面是一些示例方案，其中的自定义角色可以提高应用程序安全性。

方案	自定义角色数据操作
包含基础地图图块但没有其他 REST API 的面向公众或交互式登录网页。	`Microsoft.Maps/accounts/services/render/read`
只需要反向地理编码而无需其他 REST API 的应用程序。	`Microsoft.Maps/accounts/services/search/read`
安全主体的一个角色，请求读取基于 Azure Maps 创建者的地图数据和基础地图图块 REST API。	%>
安全主体的一个角色，要求能读取、写入和删除基于创建者的地图数据。定义为地图数据编辑器角色，但不允许访问基础地图图块等其他 REST API。	.- .

了解范围

创建角色分配时，它是在 Azure 资源层次结构中进行定义。层次结构的顶部是管理组，最底部则是 Azure 资源，例如 Azure Maps 帐户。如果为某个资源组分配了角色分配，则将允许访问该组中的多个 Azure Maps 帐户或资源。

提示

Microsoft 的一般建议是将访问权限分配到 Azure Maps 帐户作用域，因为这样可以避免对同一 Azure 订阅中现有的其他 Azure Maps 帐户进行意外的访问。

禁用本地身份验证

Azure Maps 帐户支持管理 API 中 Microsoft.Maps/accounts 的名为 disableLocalAuth 的标准 Azure 属性。如果为 true，则禁用对 Azure Maps 数据平面 REST API 的所有身份验证，但 Microsoft Entra 身份验证除外。它使用 Azure Policy 进行配置，以控制共享密钥和 SAS 令牌的分发和管理。有关详细信息，请参阅什么是 Azure Policy？。

禁用本地身份验证的操作不会立即生效。请等待几分钟，使服务阻止将来的身份验证请求。要重新启用本地身份验证，请将属性设置为 false，几分钟后，将继续进行本地身份验证。

{
  // omitted other properties for brevity.
  "properties": {
    "disableLocalAuth": true
  }
}

共享访问签名令牌身份验证

共享访问签名 (SAS) 令牌是使用 JSON Web 令牌 (JWT) 格式创建的身份验证令牌，通过加密签名来证明应用程序对 Azure Maps REST API 的身份验证。 SAS 令牌是通过将用户分配的托管标识与 Azure 订阅中的 Azure Maps 帐户集成来创建的。用户分配的托管标识通过 Azure RBAC 使用内置或自定义角色定义来获取对 Azure Maps 帐户的授权。

Microsoft Entra 访问令牌中 SAS 令牌的功能性关键差异：

令牌生存期最长为一天（24 小时）。
每个令牌的 Azure 位置和地域访问控制。
每个令牌的速率限制为每秒大约 1 到 500 个请求。
令牌的私钥是 Azure Maps 帐户资源的主密钥和辅助密钥。
用于身份验证的服务主体对象由用户分配的托管标识提供。

SAS 令牌是不可变的。这意味着在创建令牌后直到到期日期之前，SAS 令牌均有效，并且允许的区域、速率限制和用户分配的托管标识的配置无法更改。请详细阅读下面的了解访问控制，以了解 SAS 令牌撤销和访问控制更改。

了解 SAS 令牌速率限制

SAS 令牌最大速率限制可以控制 Azure Maps 资源的计费

指定对令牌的最大速率限制（maxRatePerSecond）后，超出速率将不会对帐户计费，因此可以在使用令牌时，可以为帐户设置可计费事务的上限。但在达到限制后，应用程序将接收到所有事务的客户端错误响应 429 (TooManyRequests)。应用程序负责管理 SAS 令牌的重试和分发。可以为帐户创建的 SAS 令牌数量没有限制。如果要支持现有令牌上限的提高或降低，必须创建 SAS 令牌。旧 SAS 令牌在过期之前仍然有效。

估计的示例：

大概的每秒最大速率	每秒实际速率	稳定速率持续时间（秒）	可计费事务总数
10	20	600	6,000

实际速率限制会有所不同，具体取决于在一段时间内强制实施一致性的 Azure Maps 功能。但是，这可以对计费成本进行预防性控制。

按 Azure 位置实施速率限制，而不是在全局或按地理位置实施

例如，maxRatePerSecond 为 10 的单个 SAS 令牌可用于限制 East US 位置的吞吐量。如果在 West US 2 中使用了相同的令牌，则将创建一个新的计数器，以将该位置的吞吐量限制为 10，而不考虑 East US 位置。为了控制成本和提高可预测性，我们建议：

在创建 SAS 令牌时，对目标地理位置使用指定的和允许的 Azure 位置。继续阅读以了解如何创建 SAS 令牌。
使用地理数据平面 REST API 终结点 https://us.atlas.microsoft.com 或 https://eu.atlas.microsoft.com。

请考虑应用程序拓扑，其中的终结点 https://us.atlas.microsoft.com 路由到托管 Azure Maps 服务的美国位置，例如 East US、West Central US 或 West US 2。该思路同样适用于其他地理终结点，例如 West Europe 和 North Europe 之间的 https://eu.atlas.microsoft.com。若要防止意外拒绝授权，所用 SAS 令牌应与应用程序使用相同的 Azure 位置。终结点位置使用 Azure Maps 管理 REST API 定义。

默认速率限制优先于 SAS 令牌速率限制

如 Azure Maps 速率限制中所述，单独的服务产品具有不同的速率限制，并按帐户集合实施。

请考虑搜索服务 - 非批处理反向的情况，它在下表中的每秒查询数 (QPS) 限制为 250。每个表都表示根据示例使用情况估计的成功事务总数。

第一个表显示 1 个令牌，该令牌的每秒请求数上限为 500，而应用程序在 60 秒持续时间内的实际使用情况为 500 次请求/秒。 搜索服务 - 非批处理反向的速率限制为 250，这表示在 60 秒内发出了总计 30000 次请求；其中的 15000 次请求为可计费事务。剩余的请求将产生状态代码 429 (TooManyRequests)。

名称	大概的每秒最大速率	每秒实际速率	稳定速率持续时间（秒）	大概的成功事务总数
令牌	500	500	60	~15,000

例如，如果创建了两个 SAS 令牌，并使用与 Azure Maps 帐户相同的位置，则每个令牌现在共享默认速率限制 250 QPS。如果同时使用吞吐量相同的每个令牌，则令牌 1 和令牌 2 将各成功授予 7500 个成功事务。

名称	大概的每秒最大速率	每秒实际速率	稳定速率持续时间（秒）	大概的成功事务总数
令牌 1	250	250	60	~7500
令牌 2	250	250	60	~7500

了解 SAS 令牌访问控制

SAS 令牌使用 RBAC 来控制对 REST API 的访问。创建 SAS 令牌时，会为 Maps 帐户上的先决条件托管标识分配一个 Azure RBAC 角色，该角色授予对特定 REST API 操作的访问权限。请参阅选取角色定义以确定应用程序允许使用的 API。

如果要在 SAS 令牌过期之前分配临时访问权限并移除访问权限，可撤销令牌。撤销访问权限的其他原因可能是，如果令牌无意中随 Azure Maps Data Contributor 角色分配一起分发，则具有 SAS 令牌的任何人都可以读取数据以及将数据写入 Azure Maps REST API，这些 API 可能会公开敏感数据或因使用而造成意外的财务成本。

撤销 SAS 令牌的访问权限有 2 个选项：

重新生成 SAS 令牌使用的密钥或地图帐户的 secondaryKey。
删除关联地图帐户上托管标识的角色分配。

警告

删除 SAS 令牌使用的托管标识或撤销托管标识的访问控制将导致使用 SAS 令牌和托管标识的应用程序实例有意从 Azure Maps REST API 返回 401 Unauthorized 或 403 Forbidden，从而造成应用程序中断。

为了避免中断：

将第二个托管标识添加到 Maps 帐户，并授予新托管标识正确的角色分配。
使用 secondaryKey 或与前一身份不同的托管身份创建 SAS 令牌作为 signingKey，并将新的 SAS 令牌分发到应用程序。
重新生成主密钥，从帐户中删除托管标识，并删除托管标识的角色分配。

创建 SAS 令牌

若要创建 SAS 令牌，必须具有 Contributor 角色访问权限，以管理 Azure Maps 帐户和 Azure 订阅中的用户分配的标识。

重要

在 Azure 位置 global 中创建的现有 Azure Maps 帐户不支持托管标识。

首先，应在 Azure Maps 帐户所在位置创建用户分配的托管标识。

提示

应该对托管标识和 Azure Maps 帐户使用相同的位置。

创建托管标识后，可以创建或更新 Azure Maps 帐户并附加它。有关详细信息，请参阅管理 Azure Maps 帐户。

使用托管标识成功创建或更新帐户后；可将托管标识基于角色的访问控制分配给在帐户范围的 Azure Maps 数据角色。这样，托管标识就有权访问地图帐户的 Azure Maps REST API。

接下来，使用 Azure 管理 SDK 工具、帐户管理 API 上的 List SAS 操作，或地图帐户资源的 Azure 门户共享访问签名页创建 SAS 令牌。

SAS 令牌参数：

参数名称	示例值	说明
signingKey	`primaryKey`	必需，signingKey 的字符串枚举值 `primaryKey`、`secondaryKey` 或托管标识用于创建 SAS 的签名。
principalId	`<GUID>`	必需，principalId 是附加到地图帐户的用户分配的托管标识的对象（主体）ID。
regions	`[ "eastus", "westus2", "westcentralus" ]`	可选，默认值为 `null`。区域控制 SAS 令牌可以在哪些区域中在 Azure Maps REST 数据平面 API 中使用。省略 regions 参数将允许在没有任何约束的情况下使用 SAS 令牌。如果与 Azure Maps 数据平面地理终结点（例如 `us.atlas.microsoft.com` 和 `eu.atlas.microsoft.com`）结合使用，将允许应用程序控制在指定地理位置内的使用。这可以防止在其他地理区域使用。
maxRatePerSecond	500	必需，授予 SAS 令牌的大概的指定每秒请求数上限。达到限制后，将限制更多吞吐量的速率，且 HTTP 状态代码为 `429 (TooManyRequests)`。
start	`2021-05-24T10:42:03.1567373Z`	必需，用于指定令牌生效的日期和时间的 UTC 日期。
expiry	`2021-05-24T11:42:03.1567373Z`	必需，用于指定令牌过期的日期和时间的 UTC 日期。开始和到期之间的持续时间不能超过 24 小时。

使用 SAS 令牌配置应用程序

在应用程序收到 SAS 令牌后，Azure Maps SDK 和/或应用程序将发送 HTTPS 请求，其中包括以下必需的 HTTP 标头，以及其他 REST API HTTP 标头：

标头名称	值
授权	jwt-sas eyJ0e….HNIVN

注意

jwt-sas 是使用 SAS 令牌表示的身份验证方案。请勿包含 x-ms-client-id 或其他授权标头或 subscription-key 查询字符串参数。

CORS 是一种 HTTP 协议，使在一个域中运行的 Web 应用程序能够访问另一个域中的资源。 Web 浏览器实施一种称为同源策略的安全限制，防止网页调用不同域中的 API；CORS 提供了一种安全的方法，允许一个域（源域）调用其他域中的 API。通过使用 Azure Maps 帐户资源，可以配置允许哪些源从应用程序访问 Azure Maps REST API。

重要

CORS 不是授权机制。如果启用了 CORS，则使用 REST API 对地图帐户的任何请求也需要有效的地图帐户身份验证方案，例如共享密钥、Microsoft Entra ID 或 SAS 令牌。

所有地图帐户定价层、数据平面终结点和位置都支持 CORS。

先决条件

为了防止在客户端执行恶意代码，新式的浏览器会阻止 Web 应用程序向正在单独的域中运行的资源发送请求。

如果不熟悉 CORS，请查看跨源资源共享 (CORS)，它允许 Access-Control-Allow-Origin 标头声明哪些源可以调用 Azure Maps 帐户的终结点。 CORS 协议不特定于 Azure Maps。

CORS 请求

来自源域的 CORS 请求可能由两个单独的请求组成：

预检请求，它查询服务施加的 CORS 限制。预检请求是必需的，除非请求是标准方法 GET、HEAD、POST 或包含 Authorization 请求标头的请求。
实际请求，它针对所需资源发出。

预检请求

执行预检请求不仅是一种安全措施，可确保服务器理解将在实际请求中发送的方法和标头，并确保服务器了解请求和信任请求来源，而且还会查询已为地图帐户建立的 CORS 限制。 Web 浏览器（或其他用户代理）发送一个包含请求标头、方法和源域的 OPTIONS 请求。如果可以通过 CORS 预检协议进行帐户身份验证，则地图帐户服务会尝试提取任何 CORS 规则。

如果无法进行身份验证，地图服务会评估预先配置的一组 CORS 规则，以指定在针对地图服务发出实际请求时，可以指定哪些源域、请求方法和请求标头。默认情况下，地图帐户配置为允许所有源以实现无缝集成到 Web 浏览器。

如果满足以下条件，则该服务将以所需的 Access-Control 标头响应预检请求：

OPTIONS 请求包含所需的 CORS 标头（Origin 标头和 Access-Control-Request-Method 标头）
身份验证成功，并且为与预检请求匹配的帐户启用了 CORS 规则。
由于在预检请求时无法指定所需的 Authorization 请求标头，因此跳过了身份验证。

当预检请求成功时，服务将使用状态代码 200 (OK) 进行响应，并在响应中包含所需的 Access-Control 标头。

如果出现以下情况，则该服务会拒绝预检请求：

如果 OPTIONS 请求不包含所需的 CORS 标头（Origin 和 Access-Control-Request-Method 标头），服务将使用状态代码 400 (Bad request) 进行响应。
如果在预检请求时身份验证成功，并且没有与预检请求匹配的 CORS 规则，则该服务将使用状态代码 403 (Forbidden) 进行响应。如果 CORS 规则配置为接受与当前浏览器客户端源请求标头不匹配的源，则可能会发生这种情况。

注意

将针对服务而不是针对请求的资源对预检请求进行评估。帐户所有者必须已经通过设置合适的帐户属性启用了 CORS，请求才能成功。

实际请求

接受预检请求并返回响应后，浏览器会根据地图服务调度实际请求。如果预检请求被拒绝，则浏览器会立即拒绝实际请求。

实际请求会被视为针对地图服务的普通请求。 Origin 标头的存在指示该请求为 CORS 请求，然后服务会按照 CORS 规则进行验证。如果找到匹配项，将向响应中添加 Access-Control 标头并将其发送回客户端。如果未找到匹配项，则响应将返回 403 (Forbidden)，以指示 CORS 源错误。

启用 CORS 策略

在创建或更新地图帐户时，其属性可指定要配置的允许来源。可以通过 Azure Maps 管理 SDK、Azure Maps 管理 REST API 和门户对 Azure Maps 帐户属性设置 CORS 规则。为服务设置 CORS 规则后，会对从另一个域对服务发出的正确授权请求进行评估，以根据指定的规则确定是否允许该请求。例如：

{
  "location": "eastus",
  "sku": {
    "name": "G2"
  },
  "kind": "Gen2",
  "properties": {
    "cors": {
      "corsRules": [
        {
          "allowedOrigins": [
            "https://www.azure.com",
            "https://www.microsoft.com"
          ]
        }
      ]
    }
  }
}

只能指定一个具有允许源列表的 CORS 规则。每个源都允许向指定源的 Web 浏览器中的 Azure Maps REST API 发出 HTTP 请求。

删除 CORS 策略

可以移除 CORS：

在 Azure 门户中手动操作
使用以下工具以编程方式：
- Azure Maps SDK
- Azure Maps 管理 REST API
- ARM 模板

提示

如果使用 Azure Maps 管理 REST API，请在请求正文中使用包含空 corsRule 列表的 PUT 或 PATCH。

{
  "location": "eastus",
  "sku": {
    "name": "G2"
  },
  "kind": "Gen2",
  "properties": {
        "cors": {
          "corsRules": []
        }
    }
  }
}

了解计费事务

Azure Maps 遇到以下情况时不会计算计费事务个数：

5xx HTTP 状态代码
401（未授权）
403（已禁止）
408（超时）
429 (TooManyRequests)
CORS 预检请求

有关计费事务和其他 Azure Maps 定价信息的详细信息，请参阅 Azure Maps 定价。

后续步骤

若要详细了解安全最佳做法，请参阅：

身份验证和授权最佳做法

如果要详细了解如何使用 Microsoft Entra ID 和 Azure Maps 对应用程序进行身份验证，请参阅：

在 Azure Maps 中管理身份验证

要详细了解如何通过 Microsoft Entra ID 对 Azure Maps 控件进行身份验证，请参阅：

使用 Azure Maps Map Control

使用 Azure Maps 进行身份验证

共享密钥身份验证

Microsoft Entra 身份验证

Azure 资源和 Azure Maps 的托管标识

配置应用程序 Microsoft Entra 身份验证

使用基于角色的访问控制进行授权

先决条件

概述

选取角色定义

自定义角色定义

了解范围

禁用本地身份验证

共享访问签名令牌身份验证

了解 SAS 令牌速率限制

SAS 令牌最大速率限制可以控制 Azure Maps 资源的计费

按 Azure 位置实施速率限制，而不是在全局或按地理位置实施

默认速率限制优先于 SAS 令牌速率限制

了解 SAS 令牌访问控制

创建 SAS 令牌

使用 SAS 令牌配置应用程序

跨源资源共享 (CORS)

先决条件

CORS 请求

预检请求

实际请求

启用 CORS 策略

删除 CORS 策略

了解计费事务

后续步骤

其他资源