Microsoft Entra 多重身份验证外部方法提供程序参考（预览版）

项目
05/03/2024

本主题介绍外部身份验证提供程序如何连接到 Microsoft Entra 多重身份验证 (MFA)。作为外部身份验证方法 (EAM)，外部身份验证提供程序可以与 Microsoft Entra ID 租户集成。 EAM 可以满足 MFA 访问资源或应用程序要求的第二个因素。 EAM 至少需要 Microsoft Entra ID P1 许可证。

当用户登录时，系统会对该租户策略进行评估。身份验证要求取决于用户尝试访问的资源。

登录可能会应用多个策略，具体取决于其参数。这些参数包括用户和组、应用程序、平台、登录风险级别等。

根据身份验证要求，用户可能需要使用其他因素登录才能满足 MFA 要求。第二个因素需要补充第一个因素的类型。

EAM 由租户管理员添加到 Microsoft Entra ID。如果租户需要 EAM 进行 MFA，则在 Microsoft Entra ID 验证以下两项因素后，登录将被视为满足 MFA 要求：

使用 Microsoft Entra ID 完成的第一个因素
使用 EAM 完成的第二个因素

该验证满足来自以下内容的两种或多种类型方法的 MFA 要求：

已知内容（知识）
已有内容（所有权）
你的身份信息（固有特性）

EAM 是在 Open ID Connect (OIDC) 基础上实施的。此实现需要至少三个面向公众的终结点：

OIDC 发现终结点，如提供程序元数据的发现中所述
有效的 OIDC 身份验证终结点
发布提供程序公共证书的 URL

让我们深入了解如何使用 EAM 进行登录：

用户尝试使用第一个因素（例如密码）登录受 Microsoft Entra ID 保护的应用程序。
Microsoft Entra ID 确定需要满足另一个因素。例如，条件访问策略需要 MFA。
用户选择 EAM 作为第二个因素。
Microsoft Entra ID 将用户的浏览器会话重定向到 EAM URL：
1. 此 URL 是从管理员创建 EAM 时预配的发现 URL 中发现的。
2. 应用程序提供过期或即将过期的令牌，其中包含用于标识用户和租户的信息。
外部身份验证提供程序验证令牌是否来自 Microsoft Entra ID，并检查令牌的内容。
外部身份验证提供程序可以选择调用 Microsoft Graph 以获取有关用户的其他信息。
外部身份验证提供程序执行其认为必要的任何操作，例如使用某些凭据对用户进行身份验证。
外部身份验证提供程序使用有效令牌（包括所有必需的声明）将用户重定向回 Microsoft Entra ID。
Microsoft Entra ID 验证令牌的签名是否来自配置的外部身份验证提供程序，然后检查令牌的内容。
Microsoft Entra ID 根据要求验证令牌。
如果验证成功，则用户满足 MFA 要求。用户可能还必须满足其他策略要求。

外部方法身份验证工作原理示意图。

使用 Microsoft Entra ID 配置新的外部身份验证提供程序

表示 EAM 需要集成才能发出 id_token_hint 的应用程序。可以通过两种方式创建应用程序：

在使用外部提供程序的每个租户中创建。
创建为一个多租户应用程序。特权角色管理员需要授予同意才能为其租户启用集成。

多租户应用程序可以降低每个租户中出现错误配置的可能性。它还允许提供程序在一个位置更改回复 URL 等元数据，而无需每个租户进行更改。

若要配置多租户应用程序，提供程序管理员必须首先：

创建 Microsoft Entra ID 租户（如果尚未创建）。
在其租户中注册应用程序。
将应用程序的受支持帐户类型设置为：任何组织目录中的帐户（任何 Microsoft Entra ID 租户 - 多租户）。
将 Microsoft Graph 的委托的权限 openid 和 profile 添加到应用程序。
不要在此应用程序中发布任何范围。
将外部标识提供者的有效 authorization_endpoint URL 作为回复 URL 添加到该应用程序。

注意

提供程序发现文档中提供的 authorization_endpoint 应作为应用程序注册时的重定向 URL 添加。否则，你会收到以下错误：ENTRA IDSTS50161：无法验证外部声明提供程序的授权网址！

应用程序注册过程会创建一个具有多个属性的应用程序。这些属性是我们的方案所必需的。

properties	说明
对象 ID	提供程序可以使用 Microsoft Graph 的对象 ID 来查询应用程序信息。提供程序可以使用对象 ID 以编程方式检索和编辑应用程序信息。
应用程序 ID	提供程序可以使用应用程序 ID 作为其应用程序的 ClientId。
主页 URL	提供程序主页 URL 不用于任何用途，但是应用程序注册过程所必需的。
回复 URL	提供程序的有效重定向 URL。其中一个应该与为提供程序租户设置的提供程序主机 URL 相匹配。注册的回复 URL 之一必须与 Microsoft Entra ID 通过主机 URL 的 OIDC 发现检索的 authorization_endpoint 的前缀相匹配。

每个租户的应用程序也是支持集成的有效模型。如果使用单租户注册，则租户管理员需要为单租户应用程序创建具有上表中属性的应用程序注册。

注意

使用 EAM 的租户需要获得对该应用程序的管理员许可。如果未授予同意，则当管理员尝试使用 EAM 时会出现以下错误：AADSTS900491：找不到服务主体<你的应用 ID>。

配置可选声明

提供程序可以通过使用 optional claims for id_token 来配置更多声明。

注意

无论应用程序是如何创建的，提供程序都需要为每个云环境配置可选声明。如果多租户应用程序用于全球 Azure 和适用于美国政府的 Azure，则每个云环境需要不同的应用程序和应用程序 ID。

将 EAM 添加到 Microsoft Entra ID

外部标识提供者信息存储在每个租户的身份验证方法策略中。提供程序信息存储为 externalAuthenticationMethodConfiguration 类型的身份验证方法。

每个提供程序在策略的列表对象中都有一个条目。每个条目都需要指明：

是否启用了该方法
可以使用该方法的包含组
无法使用该方法的排除组

条件访问管理员可以使用“需要 MFA 授权”创建策略来设置用户登录的 MFA 要求。身份验证强度当前不支持外部身份验证方法。

有关如何在 Microsoft Entra 管理中心中添加外部身份验证方法的详细信息，请参阅在 Microsoft Entra ID 中管理外部身份验证方法（预览版）。

Microsoft Entra ID 与提供程序的交互

后续部分介绍提供程序要求，并包括与提供程序交互的 Microsoft Entra ID 的示例。

发现提供程序元数据

外部标识提供者需要提供 OIDC 发现终结点。此终结点用于获取更多配置数据。创建 EAM 时配置的发现 URL 中必需包括完整 URL，包括 .well-known/oidc-configuration。

终结点将返回托管在那里的提供程序元数据 JSON 文档。终结点还必须返回有效的内容长度标头。

下表列出了提供程序元数据中应提供的数据。此扩展性方案需要这些值。 JSON 元数据文档可能包含更多信息。

有关包含提供程序元数据值的 OIDC 文档，请参阅提供程序元数据。

元数据值	值	评论
颁发者		此 URL 应与用于发现的主机 URL 和提供商服务颁发的令牌中的 iss 声明相匹配。
authorization_endpoint		Microsoft Entra ID 与之通信以进行授权的终结点。此终结点必须作为允许应用程序的回复 URL 之一提供。
jwks_uri		Microsoft Entra ID 可在其中找到验证提供程序颁发的签名所需的公钥。 [!NOTE] 必须提供 JSON Web 密钥 (JWK) x5c 参数才能提供所提供密钥的 X.509 表示形式。
scopes_supported	openid	也可以包括其他值，但不是必需的。
response_types_supported	id_token	也可以包括其他值，但不是必需的。
subject_types_supported
id_token_signing_alg_values_supported		Microsoft 支持 RS256
claim_types_supported	normal	该属性是可选的，但如果存在该属性，则应包含正常值；也可以包括其他值。

http://customcaserver.azurewebsites.net/v2.0/.well-known/openid-configuration
{
  "authorization_endpoint": "https://customcaserver.azurewebsites.net/api/Authorize",
  "claims_supported": [
    "email"
  ],
  "grant_types_supported": [
    "implicit"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "issuer": "https://customcaserver.azurewebsites.net",
  "jwks_uri": "http://customcaserver.azurewebsites.net/.well-known/jwks",
  "response_modes_supported": [
    "form_post"
  ],
  "response_types_supported": [
    "id_token"
  ],
  "scopes_supported": [
    "openid"
  ],
  "SigningKeys": [],
  "subject_types_supported": [
    "public"
  ]
}

http://customcaserver.azurewebsites.net/.well-known/jwks
{
  "keys": [
    {
      "kty": "RSA",
      "use": "sig",
      "kid": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "x5t": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "n": "jq277LRoE6WKM0awT3b...vt8J6MZvmgboVB9S5CMQ",
      "e": "AQAB",
      "x5c": [
        "cZa3jz...Wo0rzA="
      ]
    }
  ]
}

注意

必须提供 JWK x5c 参数才能提供所提供密钥的 X.509 表示形式。

提供程序元数据高速缓存

为了提高性能，Microsoft Entra ID 会缓存提供程序返回的元数据，包括密钥。每次 Microsoft Entra ID 与外部标识提供程序通信时，提供程序元数据高速缓存都会阻止发现调用。

此缓存每 24 小时（一天）刷新一次。下面是建议提供程序滚动更新其密钥的方式：

在“jwks_uri”中发布现有证书和新证书。
继续使用现有证书进行签名，直到 Microsoft Entra ID 缓存刷新、过期或更新（每 2 天）。
切换为使用新证书进行签名。

我们不会发布密钥滚动更新的计划。必须准备好依赖服务来处理即时和定期滚动更新。我们建议使用为此目的构建的专用库，例如 azure-activedirectory-identitymodel-extensions-for-dotnet。有关详细信息，请参阅 Microsoft Entra ID 中的签名密钥滚动更新。

发现 Microsoft Entra ID 元数据

提供程序还需要检索 Microsoft Entra ID 的公钥，以验证 Microsoft Entra ID 颁发的令牌。

Microsoft Entra ID 元数据发现终结点：

全球 Azure：https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
适用于美国政府的 Azure：https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration
由世纪互联运营的 Microsoft Azure：https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration

使用令牌中的公钥标识符（JSON Web 签名 (JWS) 中的“kid”），可以确定应使用从 jwks_uri 属性检索到的哪一个密钥来验证 Microsoft Entra ID 令牌签名。

验证由 Microsoft Entra ID 颁发的令牌

有关如何验证 Microsoft Entra ID 颁发的令牌的信息，请参阅验证令牌和 ID 令牌。对于发现元数据的使用者，无需执行特殊步骤。

Microsoft 的令牌验证库包含记录的有关令牌验证细节的所有详细信息，也可以通过浏览源代码来确定这些详细信息。有关示例，请参阅 Azure 示例。

验证成功后，可以使用声明有效负载来获取用户及其租户的详细信息。

注意

请务必验证 id_token_hint，以确保 id_token_hint 来自 Microsoft 租户并代表你的集成。应全面验证 id_token_hint，特别是签名、颁发者、受众以及其他声明值。

对外部标识提供者的 Microsoft Entra ID 调用

Microsoft Entra ID 使用 OIDC 隐式流与外部标识提供者通信。使用此流时，与提供程序的通信仅通过使用提供程序的授权端点来完成。为了让提供程序知道 Microsoft Entra ID 正在向哪个用户发出请求，Microsoft Entra ID 通过 id_token_hint 参数传递一个令牌。

此调用是通过 POST 请求进行的，因为传递给提供程序的参数列表很大。较大的列表会阻止使用限制 GET 请求长度的浏览器。

身份认证请求参数如下表所示。

注意

除非下表中列出了这些参数，否则提供程序应忽略请求中的其他参数。

身份验证查询参数	值	说明
scope	openid
response_type	Id_token	用于隐式流的值。
response_mode	form_post	我们使用表单 POST 来避免大型 URL 的问题。我们预计所有参数都将在请求正文中发送。
client_id		外部标识提供者为 Microsoft Entra ID 提供的客户端 ID，例如 ABCD。有关详细信息，请参阅外部身份验证方法说明。
redirect_url		外部标识提供者将响应 (id_token_hint) 发送到的重定向统一资源标识符 (URI)。
请参阅此表后面的示例。
nonce		由 Microsoft Entra ID 生成的随机字符串。它可以是会话 ID。如果已提供，则需要在回复 Microsoft Entra ID 的响应中返回。
state		如果已传入，则提供程序应在其响应中返回状态。 Microsoft Entra ID 使用状态来保留有关调用的上下文。
id_token_hint		由 Microsoft Entra ID 为最终用户颁发，并出于提供程序的利益而传入的令牌。
声明		包含所请求声明的 JSON Blob。有关此参数格式的详细信息，请参阅 OIDC 文档中的声明请求参数以及此表后面的示例。
client-request-id	GUID 值	提供程序可以记录此值以帮助解决问题。

重定向 URI 的示例

重定向统一资源标识符 (URI) 应注册到提供程序带外。可以发送的重定向 URI 包括：

全球 Azure：https://login.microsoftonline.com/common/federation/externalauthprovider
适用于美国政府的 Azure：https://login.microsoftonline.us/common/federation/externalauthprovider
由世纪互联运营的 Microsoft Azure：https://login.partner.microsoftonline.cn/common/federation/externalauthprovider

满足 MFA 要求的 EAM 示例

下面是 EAM 满足 MFA 要求的身份验证示例。此示例可帮助提供程序了解 Microsoft Entra ID 所需的声明。

Microsoft Entra ID 使用 acr 和 amr 值的组合来验证：

用于第二因素的身份验证方法满足 MFA 要求
身份验证方法与用于完成登录 Microsoft Entra ID 的第一个因素的方法不同

{
  "id_token": {
    "acr": {
      "essential": true,
      "values":["possessionorinherence"]
    },
    "amr": {
      "essential": true,
      "values": ["face", "fido", "fpt", "hwk", "iris", "otp", "pop", "retina", "sc", "sms", "swk", "tel", "vbm"]
    }
  }
}

默认 Id_token_hint claims

本部分介绍在向提供程序发出的请求中作为 id_token_hint 传递的令牌所需的内容。令牌包含的声明可能多于下表中的声明。

声明	值	说明
iss		标识构造并返回令牌的安全令牌服务 (STS)，以及对用户进行身份验证的 Microsoft Entra ID 租户。应用应该使用声明的 GUID 部分限制可登录应用的租户集（如果适用）。颁发者应与用户登录的租户的 OIDC 发现 JSON 元数据中的颁发者 URL 相匹配。
aud		应将受众设置为 Microsoft Entra ID 的外部标识提供者的客户端 ID。
exp		过期时间设置为在发布时间后不久过期，足以避免时间偏差问题。由于此令牌不用于身份验证，因此其有效性没有理由比请求的持续时间长很多。
iat		像往常一样设置发布时间。
tid		租户 ID 用于将租户播发到提供程序。它代表用户所在的 Microsoft Entra ID 租户。
oid		Microsoft 标识平台中对象的不可变标识符。在此示例中，它是一个用户帐户。还可以使用它安全地执行授权检查，并将它用作数据库表中的密钥。此 ID 跨应用程序唯一标识用户。登录同一用户的两个不同应用程序会在 oid 声明中收到相同值。因此，oid 可用于对 Microsoft 联机服务（例如 Microsoft Graph）的查询。
preferred_username		提供一个用户可读值，用于标识令牌使用者。不保证该值在租户内唯一，仅用于显示目的。
sub		证书颁发者中最终用户的主题标识符。令牌针对其断言信息的主体，例如应用程序的用户。此值是不可变的，无法重新分配或重复使用。可使用它安全地执行授权检查（例如，使用令牌访问资源时），并可将它用作数据库表中的键。因为使用者始终会在 Microsoft Entra ID 颁发的令牌中存在，我们建议在常规用途授权系统中使用此值。但是，使用者是成对标识符 - 它对特定应用程序 ID 是唯一的。因此，如果单个用户使用两个不同的客户端 ID 登录两个不同的应用程序，这些应用程序将收到两个不同的使用者声明值。这不一定是需要的结果，具体取决于体系结构和隐私要求。另请参阅 oid 声明（在租户内的应用中保持不变）。

为了防止将令牌用于提示以外的任何用途，会将其作为过期令牌颁发。令牌已签名，并且可以使用已发布的 Microsoft Entra ID 发现元数据进行验证。

Microsoft Entra ID 中的可选声明

如果提供程序需要 Microsoft Entra ID 中的可选声明，则可以为 id_token 配置它们。有关详细信息，请参阅可选声明。

声明的推荐使用方式

Microsoft 建议使用 oid 和 tid 声明将提供程序端的帐户与 Azure AD 中的帐户相关联。这两个声明对于 Azure AD 中的帐户来说一定是唯一的。

id_token_hint 示例

下面是目录成员的 id_token_hint 示例：

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0",
  "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536093790,
  "iat": 1536093791,
  "nbf": 1536093791,
  "name": "Test User 2",
  "preferred_username": "testuser2@contoso.com"
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
  }.

下面是租户中来宾用户的 id_token 提示示例：

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/9122040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536093790,
  "iat": 1536093791,
  "nbf": 1536093791,
  "name": "External Test User (Hotmail)",
  "preferred_username": "externaltestuser@hotmail.com",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
  }.

针对外部标识提供者的建议操作

建议外部标识提供者完成以下步骤。此列表并非详尽无遗，提供程序应完成其认为合适的其他验证步骤。

在请求中：
- 确保在对外部标识提供者的 Microsoft Entra ID 调用中提供 redirect_uri。
- 确保 client_id 具有分配给 Microsoft Entra ID 的值，例如 ABCD。
- 提供程序应首先验证 Microsoft Entra ID 向其提供的 id_token_hint。
在 id_token_hint 中的声明中：
- 他们可以选择调用 Microsoft Graph 以获取有关该用户的其他详细信息。 id_token_hint 中的 oid 和 tid 声明在这方面非常有用。有关 id_token_hint 中提供的声明的详细信息，请参阅默认 id_token_hint 声明。
然后执行提供商产品要执行的任何其他身份验证活动。
然后，提供程序将根据用户操作的结果和其他因素构建并发送返回 Microsoft Entra ID 的响应，如下一节所述。

提供程序响应的 Microsoft Entra ID 处理

提供程序需要将响应发布回 redirect_uri。成功响应时应提供以下参数：

参数	价值	说明
id_token		外部标识提供者颁发的令牌。
state		与请求中传递的状态相同（如果有）。否则，不应出现此值。

成功后，提供程序将为用户颁发 id_token。 Microsoft Entra ID 使用已发布的 OIDC 元数据来验证令牌是否包含预期的声明，并对 OIDC 所需的令牌进行任何其他验证。

声明	值	说明
iss		证书颁发者 – 必须与提供程序的发现元数据中的证书颁发者相匹配。
aud		受众 – Microsoft Entra ID 客户端 ID。请参阅对外部标识提供者的 Microsoft Entra ID 调用中的 client_id。
exp		过期时间 – 像往常一样设置。
iat		颁发时间 – 像往常一样设置。
sub		主题 – 必须与发送以发起此请求的 id_token_hint 中的 sub 相匹配。
nonce		请求中传递的 nonce 相同。
acr		身份验证请求的 acr 声明。此值应与发送以发起此请求的请求中的一个值匹配。只应返回一项 acr 声明。有关声明列表，请参阅支持的 acr 声明。
amr		身份验证中使用的身份验证方法的 amr 声明。该值应以数组形式返回，并且只应返回一种方法声明。有关声明列表，请参阅支持的 amr 声明。

支持的 acr 声明

声明	备注
possessionorinherence	身份验证必须采用基于所有权或固有特性的因素进行。
knowledgeorpossession	身份验证必须采用基于知识或所有权的因素进行。
knowledgeorinherence	身份验证必须采用基于知识或固有特性的因素进行。
knowledgeorpossessionorinherence	身份验证必须采用基于知识、所有权或固有特性的因素进行。
知识	身份验证必须采用基于知识的因素进行。
possession	身份验证必须采用基于所有权的因素进行。
inherence	身份验证必须采用基于固有特性的因素进行。

支持的 amr 声明

声明	备注
face	使用面部识别进行生物识别
fido	使用 FIDO2
fpt	使用指纹进行生物识别
hwk	拥有受硬件保护的密钥的证明
iris	使用虹膜扫描进行生物识别
otp	一次性密码
pop	所有权证明
retina	视网膜扫描生物识别
sc	智能卡
sms	按文本确认已注册号码
swk	确认存在受软件保护的密钥
tel	通过电话确认
vbm	使用声纹进行生物识别

Microsoft Entra ID 要求满足 MFA 要求才能颁发包含 MFA 声明的令牌。因此，只有具有不同类型的方法才能满足第二个因素要求。如前所述，可用于满足第二个因素的不同方法类型是知识、所有权和固有特征。

Microsoft Entra ID 根据下表验证类型映射。

Claim 方法	类型	备注
face	固有特性	使用面部识别进行生物识别
fido	所有权	使用 FIDO2。某些实施可能还需要生物识别，但所有权方法类型是映射的，因为它是主要的安全属性。
fpt	固有特性	使用指纹进行生物识别
hwk	所有权	拥有受硬件保护的密钥的证明
iris	固有特性	使用虹膜扫描进行生物识别
otp	所有权	一次性密码
pop	所有权	所有权证明
retina	固有特性	视网膜扫描生物识别
sc	所有权	智能卡
sms	所有权	按文本确认已注册号码
swk	所有权	证明存在受软件保护的密钥
tel	所有权	通过电话确认
vbm	固有特性	使用声纹进行生物识别

如果未发现令牌存在问题，则 Microsoft Entra ID 会认为已满足 MFA 要求，并向最终用户颁发令牌。否则，最终用户的请求将失败。

失败通过发出错误响应参数来指示。

参数	价值	说明
错误		ASCII 错误代码，例如 access_denied 或 temporarily_unavailable。

如果响应中存在 id_token 参数，并且令牌有效，则 Microsoft Entra ID 会将请求视为成功。否则，请求将被视为失败。由于条件访问策略的要求，Microsoft Entra ID 原始身份验证尝试失败。

在重定向到提供程序后大约 10 分钟，Microsoft Entra ID 将放弃身份验证尝试的状态。

Microsoft Entra ID 错误响应处理

Microsoft Azure 服务使用 correlationId 来关联各种内部和外部系统之间的调用。它充当可能涉及多个 HTTP 调用的整个操作或流程的公共标识符。当任何操作期间发生错误时，响应将包含一个名为“关联 ID”的字段。

联系 Microsoft 支持或类似服务时，请提供此关联 ID 的值，因为它有助于更快地访问遥测和日志。

例如：

ENTRA IDSTS70002：验证凭据时出错。 ENTRA IDSTS50012：来自证书颁发者“https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa”的外部 ID 令牌签名验证失败。令牌的 KeyID 为“A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u”，跟踪 ID：0000aaaa-11bb-cccc-dd22-eeeeee333333，相关 ID：aaaa0000-bb11-2222-33cc-444444dddddd，时间戳：2023-07-24 16:51:34Z

自定义控件和 EAM

在 Microsoft Entra ID 中，EAM 和条件访问自定义控件可以在客户准备并迁移到 EAM 时并行运行。

当前通过使用自定义控件与外部提供程序集成的客户可以继续使用它们以及他们配置用于管理访问的任何条件访问策略。建议管理员在迁移期间创建一组并行的条件访问策略：

策略应使用需要多重身份验证授权控件而不是自定义控件授权。

注意

EAM 无法满足基于身份验证强度（包括内置 MFA 强度）的授权控件要求。策略只能配置为需要多重身份验证。我们正在积极努力支持 EAM 的身份验证强度。
可以先对一部分用户测试新策略。测试组将从需要自定义控件的策略中排除，并包含在需要 MFA 的策略中。管理员确信 EAM 满足需要 MFA 的策略后，就可以将所有必需的用户包含在具有 MFA 授权的策略中，并且为自定义控件配置的策略可以移至“关闭”。

集成支持

如果在构建 EAM 与 Microsoft Entra ID 集成时遇到任何问题，可以向 Microsoft 客户体验工程 (CxE) 独立解决方案供应商 (ISV) 寻求帮助。若要与 CxE ISV 团队合作，请提交帮助请求。

参考

OAuth2.0 和 OIDC 规范

术语表

术语	说明
MFA	多重身份验证。
EAM	外部身份验证方法是来自 Microsoft Entra ID 之外的提供程序的身份验证方法，在对用户进行身份验证时使用。
OIDC	Open ID Connect 是基于 OAuth 2.0 的身份验证协议。
00001111-aaaa-2222-bbbb-3333cccc4444	用于外部身份验证方法的集成 appid 示例。

后续步骤

有关如何在 Microsoft Entra 管理中心中配置 EAM 的详细信息，请参阅在 Microsoft 中管理外部身份验证方法（预览版）。

通过