理解開放授權 (OAuth) 的安全風險：從裝置驗證碼釣魚到令牌濫用

(圖片由生成式AI創建，並經人類專業監督及審核。)

開放授權 (Open Authorisation) 是現代身份驗證及授權機制的重要基礎，讓使用者可在不共享帳戶密碼的情況下，授權應用程式存取特定資源。這種設計大幅提升了使用便利性和服務整合能力，並已廣泛應用於雲端平台、企業協作工具及各類第三方服務。

然而，近年的威脅情報顯示，攻擊者正愈來愈多地利用開放授權的合法機制發動攻擊，尤其針對存取令牌、更新令牌及授權流程進行濫用。這類攻擊不一定依賴傳統的帳密竊取，亦不一定使用假冒登入頁面，因此更容易繞過傳統保安控制，包括釣魚網站偵測、連結掃描及多重因素驗證。

開放授權的攻擊趨勢

與傳統釣魚不同， 開放授權相關的攻擊的重點並不一定在於竊取密碼，而是透過授權或令牌機制取得未授權存取。

近年值得關注的其中一種較開放授權攻擊手法是裝置驗證碼釣魚。此攻擊利用原本為輸入能力有限裝置而設的裝置驗證碼流程，誘使受害者在合法的登入頁面完成驗證，從而讓攻擊者取得有效存取令牌。微軟指出，裝置驗證碼釣魚可讓攻擊者在受害者完成合法登入後即時取得令牌，而於 2026 年發生的大規模AI 輔助裝置驗證碼攻擊活動更顯示，攻擊者已利用自動化基礎設施及即時產生驗證碼的方式，來提高攻擊成功率，顯示此類威脅持續演變。

另一類與開放授權相關的攻擊的方式是濫用重導向，攻擊者把受害者由看似可信的身份提供者頁面轉送至攻擊者控制的基礎設施，以繞過傳統電郵及瀏覽器防護。

這些發展都反映，身份攻擊正由傳統帳密竊取，逐步轉向濫用合法授權流程與工作階段。

裝置驗證碼釣魚

裝置驗證碼流程原本是為智能電視、印表機、物聯網裝置及其他輸入能力有限的設備而設。此流程會要求使用者在另一部裝置的瀏覽器中開啟指定頁面，並輸入系統顯示的短碼，以完成登入程序。

在此攻擊中，攻擊者會先建立一個合法的裝置登入請求，並取得有效的驗證碼。其後，攻擊者透過電郵或訊息平台向受害者發出釣魚訊息，誘使其前往合法頁面輸入該驗證碼。當受害者完成身份驗證及多重因素驗證後，攻擊者即可利用該流程取得相應的存取令牌及更新令牌，從而存取受害者帳戶及相關資源。

相關攻擊活動曾利用模仿 Microsoft Teams 邀請的形式進行社交工程。其後觀察到的大規模攻擊亦使用更高度個人化的主題，包括報價請求、發票及與工作角色相關的業務內容，以提升受害者互動機會。這類手法顯示，攻擊者不再單靠大規模撒網式釣魚，而是更有系統地把合法登入流程包裝為日常工作步驟。

令牌濫用

在正常的開放授權流程中，當使用者完成登入及授權後，系統會發出存取令牌及（部分情況下）更新令牌，以供應用程式在後續請求中代表使用者存取資源。

在令牌濫用攻擊中，攻擊者通常不會直接竊取帳戶密碼，而是透過釣魚、惡意應用程式或被操控的授權流程，誘使使用者在不知情下完成授權。一旦授權完成，攻擊者便可取得有效令牌，並利用該令牌在背景持續存取相關系統。

例如，在一個常見攻擊情境中，使用者可能透過看似正常的應用程式登入畫面完成身份驗證及多重因素驗證，但該授權其實已被攻擊者預先建立及控制。當授權成功後，攻擊者即可使用所得的存取令牌呼叫應用程式介面，例如讀取電郵、下載文件或存取雲端資源，整個過程無需再次觸發登入機制。

若攻擊者同時取得更新令牌，更可在原有存取令牌過期後持續換取新的令牌，延長未授權存取時間。由於所有操作均建立於合法授權之上，相關活動可能被視為正常應用程式行為，從而增加偵測難度。

濫用重導向

在開放授權的授權流程中，重導向機制用於在身份提供者與應用程式之間傳遞授權結果。當使用者完成登入或同意授權後，系統會把使用者重新導向至指定的應用程式網址，並附帶授權相關資料。

在重導向濫用攻擊中，攻擊者會利用這種合法機制，把受害者引導至預期以外的目的地。例如，攻擊者可發送釣魚連結，誘使使用者進入看似可信的身份驗證頁面，並在過程中觸發一連串合法重導向。

當使用者完成登入或授權後，系統可能會把使用者導向一個看似正常的應用程式頁面，但實際上該重導向已被操控，最終把使用者帶到攻擊者控制的網站或內容投遞平台。在這個過程中，使用者往往只觀察到官方網站及合法頁面，難以察覺整個導向鏈已被利用。

這類攻擊可被用於進一步的釣魚行為或惡意程式投遞，例如顯示偽裝成企業系統的下載頁面，或引導使用者執行含有惡意內容的檔案。由於整個流程部分建立在合法授權機制之上，因此較容易繞過電郵安全閘道及瀏覽器保護機制。

為何開放授權相關的攻擊較難偵測

開放授權相關的攻擊的危險之處，在於其濫用的是合法的身份驗證及授權機制，而非傳統的假冒登入頁面。對使用者而言，登入頁面可能確實屬官方網站，驗證程序亦可能真實存在，因此較難察覺異常。對機構而言，若監察重點只集中於密碼輸入異常或基本多重因素驗證狀態，便可能不足以識別以令牌為核心的身份攻擊。

此外，若攻擊者已取得有效存取令牌，便可能在令牌有效期內持續存取相關資源；若同時取得更新令牌，更可能延長未授權存取時間。微軟亦指出，與開放授權相關的重導向濫用活動可透過看似正常的授權流程，把受害者導向惡意內容或惡意程式投遞鏈，進一步增加防禦難度。

IETF 於 RFC 9700 中指出，開放授權 (OAuth) 2.0 的最新安全最佳現行實務已更新及延伸原有威脅模型，並將部分較不安全的運作模式列為不建議使用。

風險影響

從官方文件及公開研究可見，開放授權相關的攻擊帶來的風險，不應只被視為單一身份驗證事件的問題。若攻擊者成功取得令牌或濫用授權流程，相關風險可延伸至電郵、文件、雲端服務及其他受保護資源，並可能進一步影響企業工作流程及資料安全。

對機構而言，這些風險亦反映出身份防護工作不應只停留於密碼及基本多重因素驗證管理層面，而應進一步納入令牌治理、授權活動監察、應用程式同意管理及較安全的開放授權實作模式，才能更完整地降低現代身份攻擊風險。

保安建議

1. 限制或封鎖裝置驗證碼流程

如機構並無明確業務需要，應考慮透過條件式存取限制或封鎖裝置驗證碼流程。裝置驗證碼流程屬較高風險的身份驗證方法，可能被用於釣魚攻擊或在未受管理裝置上存取企業資源。若確有需要使用，亦應只限於已明確界定及受控的應用場景。

2. 先以監察模式模式審視影響，再正式執行封鎖政策

建議機構在正式啟用封鎖政策前，先使用監察模式評估影響，確認是否存在仍需使用裝置驗證碼流程的合法情境。同時，機構亦應審慎管理例外名單，例如緊急存取帳戶，並定期檢視相關安排。

3. 加強監察使用裝置驗證碼流程的登入活動

機構應把使用裝置驗證碼流程的登入活動視為高價值監察訊號，並留意異常 IP 地址、可疑地理位置、不尋常的登入模式及後續令牌使用情況。攻擊者可透過此流程取得有效的存取令牌及更新令牌，並利用這些令牌持續存取受害者帳戶及相關資源。

4. 收緊應用程式授權管理

由於開放授權攻擊可涉及惡意應用程式或經操控的授權流程，機構應檢視應用程式授權安排，避免使用者在缺乏適當審批下，自行授予高風險或不必要的第三方應用程式存取企業資源。對高權限授權要求，宜採取更嚴格的審批及監管措施。

5. 加強令牌管控治理及最小權限控制

開放授權的安全風險不僅在於登入過程，更在於令牌一旦被濫用，攻擊者便可能在無需再次輸入密碼的情況下持續存取資源。機構應把令牌管控納入身份防護策略的一部分，並按照最小權限原則，限制令牌權限、範圍及可存取資源，以降低令牌被盜用後造成的影響。

6. 優先採用較安全的開放授權實作方式

根據微軟及 IETF 的最新安全指引，機構在設計或採用開放授權機制時，應優先使用較安全的授權流程及保護措施。例如，建議應用程式優先使用配合 PKCE 的授權碼流程；而 IETF 的開放授權 (OAuth) 2.0 安全最佳現行實務亦指出，部分較舊或較不安全的運作模式已不再建議使用。

7. 檢視 重導向及相關授權設定

攻擊者可濫用開放授權的合法重導向機制，藉此將受害者由可信任的身份提供者頁面轉至惡意基礎設施。機構應檢視與開放授權相關的應用程式設定、重導向安排及異常授權活動，以減低此類以合法流程作掩飾的釣魚及惡意程式投遞風險。

8. 提升員工對 授權型釣魚攻擊 的警覺

機構應加強員工對裝置驗證碼釣魚及其他開放授權授權型釣魚攻擊的認識，提醒員工不要因看見官方登入頁面便放下警覺，亦不要在未經核實情況下輸入由第三方提供的驗證碼，或授權來源不明的應用程式。使用者應明白，即使登入頁面屬官方網站，整個流程亦未必代表安全。

參考資料：

• Microsoft Security Blog：Storm-2372 conducts device code phishing campaign [Microsoft]
• Microsoft Security Blog：Inside an AI-enabled device code phishing campaign [Microsoft]
• Microsoft Security Blog：OAuth redirection abuse enables phishing and malware delivery [Microsoft]
• Microsoft Learn：Authentication flows as a condition in Conditional Access policy [Microsoft Learn]
• Microsoft Learn：Block authentication flows with Conditional Access policy [Microsoft Learn]
• Microsoft Learn：Microsoft identity platform and the OAuth 2.0 device authorization grant flow [Microsoft Learn]
• IETF Datatracker：RFC 9700 - Best Current Practice for OAuth 2.0 Security [IETF]