Microsoft App Password 的安全悖論：一場設計過渡期的模糊帳

在部署或維護 Microsoft 365 郵件服務的過程中，許多技術人員或開發者可能曾因 "應用程式密碼（App Password）" 而陷入長時間測試與除錯的迴圈。這篇文章希望從中立的角度，釐清 App Password 的實際功能限制，避免大家重複走過不必要的彎路。

一、什麼是 App Password？

• 舊版 Outlook（2010 或更早）
• 不支援 OAuth 的 IMAP 或 POP 郵件工具
• 一些不支援現代驗證的桌面程式

Microsoft 原意是提供過渡期的相容方案，並非長期使用建議。

請特別注意：App Password 僅支援收信， 完全不支援 SMTP 發信。這是最容易誤判的重點。

二、App Password 的 SMTP 限制

許多人在使用 App Password 結合 SMTP 發信時會遭遇如下錯誤：

535 5.7.3 Authentication unsuccessful

這並非密碼錯誤，而是 Microsoft 明確不支援使用 App Password 登入 SMTP（smtp.office365.com）。即使在管理中心開啟 SMTP AUTH 設定，也無法繞過這一限制。

這點在 Microsoft 官方文件中有清楚說明（參考來源於文末），但在實際設定介面中缺乏明確提示，導致使用者誤以為 SMTP 也是可用場景之一。

三、哪些協議仍支援 App Password？

四、這樣的設計會讓人混淆嗎？

坦白說，會。

使用者看到可以產生 App Password，直覺會認為這是一組可以讓應用完整收發信的密碼，卻在實作 SMTP 時失敗。這樣的體驗會讓使用者以為自己設定錯誤、密碼錯誤、權限不足，進而浪費時間進行交叉測試與錯誤診斷。

從安全演進的角度來看，這是合理的政策取向。但從產品體驗角度來看，若能在產生 App Password 的介面註明其適用協議範圍，將大幅減少混淆。

五、該怎麼做才正確？

若你需要使用 SMTP 發信，請考慮以下方案：

1. ✅ 升級應用程式，改用支援現代驗證（Modern Authentication）
2. ✅ 改採 Microsoft Graph API 實作 sendMail 功能
3. ✅ 若為共用信箱發信需求，請確保使用者擁有 Send As 權限，並以支援 OAuth2 的程式操作

六、結語：從過渡工具到現代架構

App Password 是一個在雲端轉型過程中被引入的妥協方案，最初的設計是合理的。但隨著 Microsoft 365 架構趨於完整，支援 OAuth2 幾乎成為所有應用的基本要求。

這篇文章希望能幫助你釐清 App Password 的定位，避免浪費不必要的設定時間，並順利將系統架構導向更穩定與現代的驗證方式。

參考資料：

• Microsoft Learn: Create an app password
• Microsoft Learn: Enable or disable SMTP AUTH

支援 Microsoft 365 OAuth 2.0 的郵件客戶端清單（參考用）

提醒：各郵件客戶端需為最新版，並正確設定為 OAuth 模式，才能正常通過驗證與授權流程。