1. Azure Active Directory B2C (AAD B2C) 中的 SMS/OTP 身份验证
1.1. 现状与原理：电话注册与登录
Azure Active Directory B2C (AAD B2C) 提供了将电话号码作为用户身份标识进行注册和登录的功能，旨在为用户提供一种便捷的替代传统电子邮件或用户名登录的方式。此功能允许用户使用其电话号码作为主要登录凭据，或者作为现有登录方法的补充。在用户流中启用电话注册和登录后，用户可以选择使用电话号码创建新账户或登录现有账户。此过程通常涉及用户输入其电话号码，然后通过短信 (SMS) 或语音通话接收一次性密码 (OTP) 以验证其所有权。AAD B2C 直接与 Azure AD 多重身份验证 (MFA) 集成，这意味着在注册或登录流程中可以无缝地加入第二层安全验证 。这种集成使得应用程序能够处理多种场景，例如，要求访问某个敏感应用程序时必须进行 MFA，而对其他应用程序则不需要，或者在执行敏感操作（如资金转账）前必须验证电话号码 。
在 AAD B2C 中配置电话注册和登录涉及几个关键步骤。首先，需要在租户范围内的本地账户身份提供者中配置电话注册和登录 ，以接受电话号码作为用户身份 。然后，可以将电话注册添加到用户流中，从而允许用户使用其电话号码注册应用程序。此外，还可以启用恢复电子邮件提示（预览版） ，允许用户指定一个电子邮件地址，以便在无法使用手机时恢复其账户 。在用户注册或登录流程中，还可以向用户显示同意信息，可以是默认信息，也可以是自定义的同意信息 。值得注意的是，当使用电话注册配置用户流时，默认情况下会禁用多重身份验证 (MFA) 。虽然可以在具有电话注册的用户流中启用 MFA，但由于电话号码已用作主要标识符，因此电子邮件一次性密码是第二个身份验证因素的唯一可用选项 。另外，根据 Microsoft Learn 文档 ，从2025年5月1日起，AAD B2C 将不再向新客户提供购买，现有客户可继续使用，但新客户需考虑替代方案。
1.2. 实践：配置用户流与自定义策略
在 Azure Active Directory B2C (AAD B2C) 中，实现一次性密码 (OTP) 验证通常涉及到自定义策略的配置。AAD B2C 允许通过定义技术配置文件 (Technical Profile) 来管理 OTP 的生成和验证过程 。这些技术配置文件是 XML 文件，身份开发者可以利用它们来编程实现身份任务，例如使用 OpenID Connect、OAuth 或 SAML 等标准协议对用户进行身份验证 。自定义策略还支持 REST API 调用，这在需要通过用户信息端点检索用户声明时非常有用 。AAD B2C 自定义策略入门包提供了一些预构建的策略，以帮助快速上手 。
OTP 技术配置文件的核心功能包括生成验证码和后续验证该验证码 。该技术配置文件可以配置为两种模式：生成代码 (GenerateCode) 和验证代码 (VerifyCode) 。在生成代码模式下，可以配置多种参数来控制 OTP 的生成，例如代码长度 (CodeLength，默认为6位)、字符集 (CharacterSet，默认为0-9，但必须至少包含10个不同的字符)、代码过期时间 (CodeExpirationInSeconds，默认为600秒，范围60-1200秒)、最大验证尝试次数 (NumRetryAttempts，默认为5次) 以及每个标识符的最大代码生成尝试次数 (NumCodeGenerationAttempts，默认为10次) 。此外，还可以配置是否在代码未过期且仍然有效时重复使用相同的代码 (ReuseSameCode，默认为 false) 。生成的代码和尝试次数会在会话中进行跟踪 。
在生成代码模式下，输入声明 (InputClaims) 通常包含一个标识符 (identifier)，用于识别需要验证代码的用户，通常是代码交付目的地的标识符，例如电子邮件地址或电话号码 。输出声明 (OutputClaims) 则包含生成的 OTP 代码 (otpGenerated)，该代码的会话由 AAD B2C 管理 。在验证代码模式下，输入声明包括之前生成代码的用户的标识符 (identifier) 以及用户提供的待验证代码 (otpToVerify) 。验证成功后，用户旅程将继续；如果验证失败，则可以配置错误消息并通过验证技术配置文件 (Validation Technical Profile) 在自断言页面上显示 。OTP 技术配置文件的协议名称 (Protocol Name) 属性必须设置为 Proprietary ，处理程序 (Handler) 属性必须包含 Azure AD B2C 使用的协议处理程序程序集的完全限定名称：Web.TPEngine.Providers.OneTimePasswordProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null 。
集成 SMS 和 TOTP (基于时间的一次性密码) 多因素认证 (MFA) 方法到自定义策略中，可以让用户选择其中一种方式，并将其配置保存在 AAD B2C 中 。在后续登录时，系统会要求用户使用已配置的 MFA 方法进行身份验证 。这通常涉及到定义一系列声明类型 (Claim Types)、声明转换 (Claims Transformations) 和技术配置文件，例如创建完整电话号码、验证电话号码、发送 SMS、验证 SMS、写入 MFA 方法和电话号码以及获取 MFA 声明等技术配置文件 。同时，还需要通过自断言技术配置文件 (Self Asserted Technical Profiles) 来收集用户输入，例如选择 MFA 方法、配置电话号码、通过 SMS 发送代码以及输入通过 SMS 发送的验证码等步骤 。最后，这些技术配置文件和用户旅程 (User Journey) 以及子旅程 (Sub Journey) 进行集成，以实现完整的 MFA 流程 。值得注意的是，AAD B2C 的本地化功能目前不直接支持 SMS 消息的自定义 。然而，可以通过使用第三方 SMS 提供商（如 Twilio）或自定义 SMS 提供商，并结合 DisplayControls 来实现自定义上下文 SMS 消息、自定义电话号码以及支持本地化和自定义 OTP 设置 。例如，可以使用 PhoneFactor 技术配置文件在自定义策略中向特定电话号码发送 SMS 消息，该技术配置文件将 SMS 发送到输入声明中指定的电话号码 。
下表总结了 OTP 技术配置文件在生成代码 (GenerateCode) 和验证代码 (VerifyCode) 模式下的关键配置参数：
| 参数 (元数据项) | 模式 | 描述 | 默认值/范围/示例 |
|---|---|---|---|
| Operation | GenerateCode | 指定操作为生成代码。 | GenerateCode |
| VerifyCode | 指定操作为验证代码。 | VerifyCode |
|
| CodeExpirationInSeconds | GenerateCode | 代码过期时间（秒）。 | 默认 600 (范围 60-1200) |
| CodeLength | GenerateCode | 生成的 OTP 代码的长度。 | 默认 6 |
| CharacterSet | GenerateCode | 代码的字符集，使用正则表达式格式。必须至少包含 10 个不同字符。 | 默认 0-9 (示例: a-z0-9A-Z) |
| NumRetryAttempts | GenerateCode | 代码被视为无效之前的验证尝试次数。 | 默认 5 |
| NumCodeGenerationAttempts | GenerateCode | 每个标识符的最大代码生成尝试次数。 | 默认 10 |
| ReuseSameCode | GenerateCode | 如果代码未过期且仍然有效，是否应提供相同的代码而不是生成新代码。 | 默认 false |
| UserMessageIfSessionDoesNotExist | VerifyCode | 会话不存在时的用户消息。 | 可本地化的错误消息 |
| UserMessageIfMaxRetryAttempted | VerifyCode | 达到最大重试次数时的用户消息。 | 可本地化的错误消息 |
| UserMessageIfMaxNumberOfCodeGenerated | VerifyCode | 代码生成达到最大尝试次数时的用户消息。 | 可本地化的错误消息 |
| UserMessageIfInvalidCode | VerifyCode | 提供无效代码时的用户消息。 | 可本地化的错误消息 |
| UserMessageIfVerificationFailedRetryAllowed | VerifyCode | 提供无效代码但允许重试时的用户消息。 | 可本地化的错误消息 |
| UserMessageIfSessionConflict | VerifyCode | 无法验证代码时的用户消息。 | 可本地化的错误消息 |
Table 1: OTP 技术配置文件关键配置参数
1.3. 限制与注意事项：MFA 与 SMS 作为第二因素
在 Azure AD B2C 中配置 SMS 和 OTP 作为身份验证方法时，存在一些限制和注意事项。首先，当在用户流中配置电话注册和登录时，如果电话号码被用作主要标识符，那么 MFA 的第二个因素唯一可用的选项是电子邮件一次性密码 。这是因为电话号码已经作为主要身份验证手段，系统默认禁用 MFA，或者更准确地说，无法使用 SMS 作为第二因素，因为 SMS 通道已被用于发送登录码。AAD B2C 直接集成了 Azure AD 多重身份验证 (MFA)，以便为应用程序中的注册和登录体验添加第二层安全性，并且可以在不编写代码的情况下启用 MFA 。
关于通过 SMS 发送 MFA 验证码的配额，Azure AD B2C 存在一些未公开的限制 ，以防止恶意攻击和欺诈活动 。如果超出这些未公开的限制，用户可能会遇到诸如"您已达到短信数量限制。请稍后再试。"或"您提供的电话号码无法接通。"之类的错误消息 。这些限制可能发生在租户级别，也可能发生在 IP/电话号码级别 。因此，在进行大量测试或生产环境部署时，需要考虑到这些潜在的节流限制。如果应用程序需要更高的重试次数，可以考虑使用自定义策略，在其中可以定义 OTP 技术配置文件并配置 NumCodeGenerationAttempts（每个标识符的最大代码生成尝试次数，默认值为 10）和 NumRetryAttempts（验证尝试次数，默认值为 5）等参数 。
在自定义策略中，如果电话号码格式不正确，更新电话号码可能会导致问题 。此外，AAD B2C 的本地化功能目前不直接支持 SMS 消息的自定义 ，这意味着默认的 SMS 消息模板可能无法满足所有业务场景的需求 。虽然可以通过集成第三方 SMS 提供商来解决此问题，但这会增加实现的复杂性和成本 。另一个需要注意的点是，Azure AD B2C 的用户界面在显示 MFA 电话号码方面可能存在不一致 。有用户报告称，新的身份验证方法用户界面不再显示通过自定义策略注册的 MFA 电话号码，尽管这些号码仍然可以通过旧的 Azure Graph API 在 strongAuthenticationDetail 字段中查看到 。这给管理员查看和管理用户的 MFA 电话号码带来了一定的困扰。最后，需要注意的是，从 2025 年 5 月 1 日起，Azure AD B2C 将不再向新客户提供购买服务 。
2. Azure Communication Services (ACS) 中的 SMS/OTP 应用
2.1. 现状与原理：ACS 的 SMS 功能概述
Azure Communication Services (ACS) 提供了一套全面的 SMS 功能，使开发者能够在其应用程序中集成发送和接收短消息服务 (SMS) 文本消息的能力 。ACS 的 SMS SDK 旨在支持多种业务场景，包括客户服务、预约提醒、双因素认证 (2FA) 以及其他需要实时通信的场景 。通过 ACS，开发者可以可靠地发送消息，并获取有关消息可交付性和响应指标的洞察 。ACS 的 SMS 功能强调简单的设置体验，使得向应用程序添加 SMS 功能变得便捷 。其关键特性包括支持通过免费电话号码和短代码在美国进行高速 A2P（应用到人）用例的消息传递；支持批量消息传递，可一次向多个收件人发送消息；支持双向对话，适用于客户支持、警报和预约提醒等场景；提供可靠的传递和实时传递报告；以及分析功能以跟踪 SMS 使用模式 。
ACS 支持多种发件人 ID 类型，以适应不同的业务需求和地区法规。这些发件人类型包括免费电话号码 (Toll-Free Number, 1-8XX) 、短代码 (Short Codes, 例如 12345) 、10 位长代码 (10 Digit Long Codes, 10DLC, 例如 1-234-123-1234) 、移动电话号码 (Mobile Numbers, 例如 +XX XXXXX XXXXX) 以及字母数字发件人 ID (Alphanumeric Sender ID, 例如 CONTOSO) 。选择正确的发件人 ID 类型对于消息传递活动的成功至关重要，需要考虑目标国家/地区、法规要求、吞吐量需求以及启动时间表等因素 。例如，在美国，ACS 支持通过免费电话号码和短代码进行高速率的应用对人 (A2P) 用例消息传递 。ACS 还支持选择退出 (Opt-Out) 处理，能够自动检测并遵守用户的退订请求，这是美国运营商对免费电话号码的强制要求 。ACS 的 SMS 和 PSTN（公共交换电话网络）功能取决于所使用的电话号码以及运营所在的国家/地区，该地区由 Azure 账单地址确定 。
2.2. 实践：发送 SMS 与 OTP
使用 Azure Communication Services (ACS) 在应用程序内发送 SMS 消息和 OTP（一次性密码）主要依赖于 ACS 提供的 SMS SDK。开发者可以利用这些 SDK 来实现各种编程语言（如 C#, JavaScript, Java, Python）的集成 。发送 SMS 消息的基本流程包括初始化 ACS 客户端，然后调用发送消息的 API，并指定发件人电话号码（从 ACS 获取的号码）和收件人电话号码，以及消息内容 。对于 OTP 场景，应用程序首先生成一个 OTP 代码，然后通过 ACS 的 SMS 功能将此代码作为短信内容发送给用户。在 ACS 中，要发送 SMS，首先需要获取一个具备 SMS 功能的电话号码 。ACS 允许获取不同类型的号码，如免费电话号码、短代码或长代码，具体选择取决于业务需求和目标地区 。
获取号码后，开发者可以使用 ACS 的 SmsClient 来发送消息。例如，在 C# 中，可以通过 SmsClient.SendAsync 方法来发送短信，该方法接受收件人电话号码、发件人电话号码和消息内容作为参数 。对于 OTP 场景，消息内容将包含生成的 OTP 代码，并通常附带一些说明文本，例如"您的验证码是：123456"。ACS 还支持更高级的 SMS 功能，如批量消息传递，允许开发者一次性向多个收件人发送消息，这对于大规模 OTP 分发或通知场景非常有用 。此外，ACS 提供了消息传递状态的实时报告和送达回执，帮助开发者监控消息的发送状态和用户的接收情况 。在某些情况下，例如将 ACS 与 Azure AD B2C 集成以实现自定义 SMS 验证时，ACS 可以作为 B2C 的 SMS 连接器。这可能涉及到配置一个 REST API 端点，该端点由 B2C 的自定义策略调用，然后此端点再通过 ACS SDK 发送 SMS 。对于 PSTN 呼叫功能，当使用 ACS 的试用电话号码时，必须验证接收方电话号码，验证过程包括 ACS 向目标号码发送一个 OTP 。
2.3. 限制与注意事项：服务限制与合规性
使用 Azure Communication Services (ACS) 发送 SMS 和 OTP 时，开发者需要关注其服务限制和合规性要求。首先，ACS 的 SMS 和 PSTN 功能受到电话号码类型和运营国家/地区的限制 ，这些限制与 Azure 账单地址相关联 。因此，在选择电话号码和规划 SMS 活动之前，务必查阅 Azure 官方文档中关于订阅资格和各国/地区号码类型可用性的详细信息 。ACS 对 SMS 消息的发送速率有限制，以防止滥用并确保服务稳定性。例如，对于免费电话号码，速率限制为每个号码每分钟 200 条消息或 200 个消息单位；对于短代码，为每个号码每分钟 6000 条消息或 6000 个消息单位；对于字母数字发送者 ID，为每个资源每分钟 600 条消息或 600 个消息单位 。如果发送或接收大量消息，可能会收到 429 错误（请求过多），表明即将达到服务限制 。
在字符和消息长度方面，单个 SMS 消息的最大大小为 140 字节。实际字符限制取决于消息内容和编码（GSM-7 或 UCS-2）。例如，使用 GSM-7 编码的纯文本消息每个段最多可包含 160 个字符，而使用 UCS-2 编码的 Unicode 消息（如包含表情符号或国际语言）每个段最多可包含 70 个字符 。虽然 ACS 支持发送和接收长消息（超过 2048 个字符），但为了确保最佳送达率，建议将 SMS 消息长度控制在 320 个字符以内 。对于美国短代码，发送或接收包含非 ASCII 字符的消息时，存在一个已知的限制，即最多四个段 。
合规性是 SMS 通信中的一个关键方面。ACS 强调了对选择退出 (Opt-Out) 处理的支持 ，特别是对于美国的免费电话号码和短代码，运营商强制要求并执行选择退出机制 。对于在美国使用免费电话号码发送 SMS，ACS 要求进行免费电话号码验证 (Toll-Free Verification) 。这个过程需要提交一份程序简介 (Program Brief) 申请，通常需要五到六周的时间 。同样，要使用 10DLC 发送 A2P SMS 消息，企业必须完成品牌注册和活动注册，以确保符合运营商和 CTIA 的指导方针 。这些合规性要求旨在防止垃圾邮件并保护用户隐私。此外，ACS 的一些功能可能处于预览状态，预览版 API 和 SDK 不提供服务级别协议 (SLA)，不建议用于生产工作负载 。开发者应关注 ACS 的定价模型，了解发送 SMS 消息的成本 。
下表总结了 ACS 中不同发件人 ID 类型的速率限制：
| 发件人 ID 类型 | 速率限制 (每分钟) | 备注 |
|---|---|---|
| 免费电话号码 (Toll-Free) | 200 条消息或 200 消息单位 | 每个号码 |
| 短代码 (Short Code) | 6000 条消息或 6000 消息单位 | 每个号码 |
| 字母数字发件人 ID | 600 条消息或 600 消息单位 | 每个资源 |
Table 2: ACS 发件人 ID 类型速率限制
下表总结了 ACS 中不同发件人 ID 类型的合规性要求：
| 发件人 ID 类型 | 主要合规性要求 | 备注 |
|---|---|---|
| 免费电话号码 (Toll-Free) | 免费电话号码验证 (Toll-Free Verification) | 美国运营商要求，提交程序简介，审核约 5-6 周 。 |
| 10 位长代码 (10DLC) | 品牌注册和活动注册 (Brand & Campaign Registration) | 美国 A2P 消息，符合运营商和 CTIA 指导方针，审核时间数天 。 |
| 所有类型 | 遵守消息传递政策，禁止垃圾邮件、欺诈性消息 | 否则可能导致服务暂停或终止。 |
| 所有类型 | 处理用户选择退出 (Opt-Out) 请求 | 美国运营商对免费电话号码和短代码的强制要求。 |
Table 3: ACS 发件人 ID 类型合规性要求
3. Azure 多重身份验证 (MFA) 中的 SMS/OTP 验证
3.1. 现状与原理：SMS 在 MFA 中的角色
在 Azure 多重身份验证 (MFA) 中，SMS（短消息服务）和 OTP（一次性密码）扮演着重要的验证因素角色，旨在为用户登录提供额外的安全层。Azure MFA 提供了多种验证方法，SMS 是其中一种常用的方式 。其基本原理是，在用户输入用户名和密码（第一因素）之后，系统会通过 SMS 向用户预先注册的手机号码发送一个包含 OTP 的文本消息 。用户随后需要在登录界面输入这个 OTP 才能完成身份验证过程 。这种方式被称为单向 SMS (one-way SMS) 。Azure MFA 也曾经支持过双向 SMS (two-way SMS)，即用户需要将特定代码回复给系统，但此方法已在 2018 年 11 月 14 日后被弃用并不再支持 。
SMS 验证作为一种"拥有的东西"（用户拥有的手机）因素，与"知道的东西"（密码）和"固有的东西"（生物特征）共同构成了多因素认证的基础。在 Azure AD B2C 中，当启用 MFA 时，用户可以在首次注册或登录时提供并验证其电话号码 。在后续的登录过程中，用户可以选择通过短信接收 OTP 代码，或者选择接听自动语音来电（如果也配置了电话呼叫验证） 。Microsoft Entra ID（以前称为 Azure Active Directory）也支持基于 SMS 的用户登录，允许用户仅使用注册的电话号码和通过 SMS 发送的 OTP 进行登录，而无需用户名和密码 。然而，这种 SMS 作为第一因素的登录方式主要设计用于简化一线员工的登录体验，并不推荐用于信息工作者 (Information Workers) 。对于信息工作者，SMS 通常作为 MFA 的第二因素。Microsoft 建议，如果为一线员工启用 SMS 认证，应考虑迁移到使用 QR 码认证（预览版），因为 QR 码认证不易受到钓鱼攻击 。尽管 SMS 作为一种便捷的 MFA 方法被广泛使用，但 Microsoft 也指出了基于电话的 MFA 响应（包括 SMS 和语音呼叫）可能不如其他方法（如验证器应用、Windows Hello 或 FIDO2 安全密钥）安全 。
3.2. 实践：配置与使用
在 Azure 多重身份验证 (MFA) 中配置和使用 SMS/OTP 验证，主要涉及到在 Azure 门户中启用相应的验证方法，并指导用户注册其电话号码。对于 Azure AD B2C，管理员可以在用户流或自定义策略中启用 MFA，并选择 SMS 作为可用的验证方法之一 。当用户注册或登录时，系统会提示他们提供并验证一个电话号码。在后续登录时，如果 MFA 被触发（例如通过条件访问策略），用户可以选择通过 SMS 接收 OTP 代码 。对于企业用户（使用 Microsoft Entra ID），管理员可以通过导航到 Microsoft Entra ID -> 用户和组 -> 所有用户 -> 每用户 MFA -> 服务设置，来选择可供用户使用的验证方法 。在这里，管理员可以勾选"短信"或"致电手机"等选项 。用户在其账户中注册 MFA 时，可以从管理员已启用的方法中选择其偏好的验证方法，通常通过 https://account.activedirectory.windowsazure.com/Proofup.aspx 等页面配置 。
在 Microsoft Entra ID 中，还可以为特定用户或组启用基于 SMS 的身份验证（作为第一因素） 。这需要至少具备身份验证策略管理员 (Authentication Policy Administrator) 角色 。启用此功能后，管理员需要为用户账户设置电话号码，用户即可在支持的应用程序登录界面输入电话号码，并通过接收到的 SMS OTP 完成登录 。需要注意的是，每个启用 SMS 认证方法的用户都必须获得许可，即使他们不使用该方法 。在 Azure AD B2C 的自定义策略中，集成 SMS 和 TOTP MFA 方法需要详细的技术配置，包括定义声明类型、声明转换以及一系列技术配置文件 。对于通过 Azure NPS (Network Policy Server) 扩展进行 MFA 的场景，如果用户使用基于文本的 MFA 方法（如 SMS），他们会收到一条包含 OTP 的短信，需要在 VPN 客户端界面输入该 OTP 。
3.3. 限制与注意事项：对信息工作者的建议与已知问题
在 Azure 多重身份验证 (MFA) 中使用 SMS/OTP 作为验证方式时，存在一些重要的限制和注意事项，特别是对于信息工作者 (Information Workers)。Microsoft 明确指出，虽然基于 SMS 的身份验证（作为第一因素）可以简化一线员工的登录体验，但并不推荐将其用于信息工作者 。对于信息工作者，更安全的 MFA 方法，如 Microsoft Authenticator 应用通知、Windows Hello 或 FIDO2 安全密钥，是更优的选择 。Microsoft 甚至建议，如果为一线员工启用了 SMS 认证，也应考虑迁移到 QR 码认证（预览版），因为 QR 码认证不易受到钓鱼攻击 。
基于电话的 MFA 响应（包括 SMS 和语音呼叫）被认为安全性较低 。SMS 消息是以明文形式发送的，存在被拦截和泄露的风险 。此外，SIM 卡交换攻击也是一个严重威胁 。存在一些已知的技术限制。例如，在 Microsoft Entra ID 中，基于 SMS 的身份验证目前与 Microsoft Entra 多重身份验证不兼容 （当 SMS 作为第一因素时）。除了 Teams 之外，基于 SMS 的身份验证与原生 Office 应用程序不兼容 。此外，基于 SMS 的身份验证不支持 B2B 账户，并且联合用户不会在本地租户中进行身份验证，而仅在云中进行身份验证 。跨租户同步也不支持启用了 SMS 登录的用户 。当使用 Azure NPS 扩展进行 MFA 时，如果用户使用基于文本的 MFA 方法（如 SMS），NPS 策略中配置的任何 RADIUS 属性可能不会转发到 RADIUS 客户端，这是一个 Microsoft NPS 扩展的已知限制 。在 Azure AD B2C 中，如果管理员从 MFA 服务中删除了某个已注册的验证方法（例如 SMS 文本）作为选项，已经使用该方法注册的用户可能会受到影响。关于 Azure AD B2C 中通过 SMS 发送 MFA 验证码的配额，存在一些未公开的限制 。
下表总结了 Azure MFA 中 SMS/OTP 验证的主要限制和建议：
| 方面 | 限制/建议 | 备注/引用 |
|---|---|---|
| 信息工作者 (IW) 使用 | 不推荐用于 IW | 建议使用更安全的验证方法 (如 Authenticator 应用, FIDO2) |
| SMS 作为第一因素 | 与 Microsoft Entra MFA 不兼容 | 主要设计用于一线员工 |
| Office 应用兼容性 | 与原生 Office 应用程序不兼容 (Teams 除外) | 可能影响 IW 日常工作 |
| B2B 账户 | 不支持 B2B 账户 | 限制在协作场景中的应用 |
| 联合用户 | 在云中进行身份验证，而非主租户 | 行为可能与本地身份验证不同 |
| 跨租户同步 | 不支持启用了 SMS 登录的用户 | 影响用户管理策略 |
| NPS 扩展 | 使用基于文本的 MFA 方法时，RADIUS 属性可能未转发 | 可能导致访问控制问题 |
| AAD B2C MFA 配额 | 通过 SMS 发送 MFA 验证码存在未公开的配额限制 | 超出限制可能导致错误 |
| 许可证 | 启用 SMS 身份验证方法的用户需要拥有相应的许可证 | 例如 Microsoft Entra ID P1/P2, EMS E3/E5, Microsoft 365 E3/E5 |
Table 4: Azure MFA 中 SMS/OTP 验证的限制和建议