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 驗證的限制和建議