繁體中文（台灣）

oauth
security
oidc
authentication

為什麼你應該廢除 Resource Owner Password Credentials (ROPC) 授權類型

Resource Owner Password Credentials (ROPC) 授權類型是一種有安全風險的舊版 OAuth 2.0 流程，應該被廢除。在本文中，我們將指出為什麼應該避免在應用程式中使用 ROPC。

Simeng

Developer

4/24/2024

不要在使用者認證上浪費數週時間

使用 Logto 更快地發布安全應用程式。幾分鐘內整合使用者認證，專注於您的核心產品。

立即開始

介紹

Resource Owner Password Credentials (ROPC) 授權類型，也被稱為密碼授權類型，是一種 OAuth 2.0 流程，允許應用程式使用者的用戶名與密碼交換存取權杖。它首先在 OAuth 2.0 規範中被引入，作為支援舊版應用程式（如 HTTP 基本認證或無法使用更安全的 OAuth 權杖化流程的舊版原生應用程式）的一種方式。

然而，ROPC 授權類型帶來幾個安全風險，並在 OAuth 2.0 安全最佳實踐中被標註為不得使用。

最近，我們收到多位客戶關於如何實施 ROPC 授權類型的指導或支援請求。在本文中，我們將解釋為什麼你應該避免使用 ROPC 授權類型，特別是在新的應用程式中。

ROPC 授權類型 vs. 授權碼流程

ROPC 授權類型是如何運作的

ROPC 授權類型是一種簡單的流程，通過交換使用者的用戶名和密碼來取得存取權杖。用戶端應用程式會直接收集使用者的憑證，並將其直接傳送到授權伺服器。授權伺服器隨後會驗證憑證並向用戶端發出存取權杖。

授權碼流程如何運作

相比之下，授權碼流程是為網路應用程式推薦的 OAuth 2.0 流程。它涉及用戶端應用程式、授權伺服器和使用者的瀏覽器之間的多步驟和重定向。授權碼流程更安全，因為它不會將使用者的憑證暴露給用戶端應用程式。

ROPC 授權類型與授權碼流程之間的主要區別在於 ROPC 將使用者的憑證暴露給用戶端應用程式，而授權碼流程不會。使用者憑證應在授權伺服器中保密。每當用戶端應用程式代替使用者請求資源時，應重定向使用者到授權伺服器以驗證和授權用戶端應用程式。這能保持最少量的授權數據在用戶端應用程式端。

ROPC 授權類型的安全風險

1. 使用者憑證暴露

如前所述，ROPC 授權類型將使用者的憑證暴露給用戶端應用程式。這是一個重大的安全風險，因為用戶端應用程式可能會儲存或記錄使用者的憑證，而無需使用者的知情再次授權。

特別是在公共用戶端應用程式（如行動應用程式或單頁應用程式）中，用戶端應用程式可能會被輕易注入或逆向工程以提取使用者的憑證。在使用者的瀏覽器中運行的行動應用程式或單頁應用程式都無法保密地保管秘密。因此，它們無法在不暴露使用者憑證的情況下進行使用者驗證。

即使資源所有者與用戶端應用程式有信任關係，用戶端應用程式在整個認證過程中扮演中間人角色，也可能被其他惡意行為者攻擊。惡意行為者可以竊取使用者的憑證並偽裝成使用者访问用户资源。

根據用戶端應用程式的安全姿態，有多種方法可以竊取使用者的憑證，如鍵盤記錄器、釣魚攻擊或惡意軟體。更不用說用戶憑證在每次授權請求中都會透過網絡傳輸，這進一步增加了憑證被截取的風險。

想像一下，如果你有多個使用 ROPC 授權類型的應用程式，憑證暴露的潛在風險倍增。

2. ROPC 不支持使用者同意

ROPC 授權類型不支持使用者同意。當用戶端應用程式直接收集使用者的憑證時，使用者沒有機會查看和批准用戶端應用程式對其資源的存取。這是對使用者隱私和信任的侵害。

使用者應有權決定哪個用戶端應用程式可以訪問他們的資源及存取多長時間。特別是對第三方應用程式來說，使用者同意機制對於保護資源所有者的數據是至關重要的，也必須符合 GDPR 等數據保護法規。

3. ROPC 不支持多因素驗證

多因素驗證（MFA）是一種要求使用者提供兩個或更多驗證因素以存取其資源的安全實施。它為驗證過程增加了額外的安全層。ROPC 授權類型不支持 MFA。相反，它將驗證過程限制為單一因素，而且權杖請求僅基於使用者的憑證。無法使用 ROPC 授權類型實施基於挑戰的驗證機制，如短信 OTP、電子郵件 OTP 或 WebAuthn。

ROPC 與現代應用程式不兼容

ROPC 授權類型旨在支援無法支援現代聯合身份系統（如單一登入或聯合身份）的舊版應用程式。

1. ROPC 與 SSO 不兼容

單一登入（SSO）是一種現代認證架構，允許使用者只需登錄一次即可輕鬆訪問多個應用程式。

集中式 IdP 在 SSO 架構中扮演至關重要的角色。它管理使用者的認證會話並向用戶端應用程式發出權杖。用戶端應用程式不需要直接收集使用者的憑證，而使用者的憑證在 IdP 中保密。

ROPC 授權類型不支持 SSO。它要求用戶端應用程式直接收集使用者的憑證，這破壞了 SSO 架構。這不適合與現代 SSO 系統（如 OpenID Connect (OIDC) 或 SAML）兼容。

2. ROPC 與聯合身份不兼容

與 SSO 架構類似，聯合身份允許使用者使用其現有的身份來存取多個第三方應用程式。使用者可以將多個社交帳號（如 Google、Facebook 或 Twitter）鏈接到集中式 IdP，並使用這些社交帳號進行用戶端應用程式的驗證。所有的聯合身份由 IdP 管理，而用戶端應用程式不會意識到使用者認證的詳細信息。

ROPC 授權類型則要求用戶端應用程式直接收集使用者的憑證。它限制了用戶端應用程式支持聯合身份的能力，並將使用者的身份數據暴露給用戶端應用程式。

結論

Resource Owner Password Credentials (ROPC) 授權類型是一種具有重大安全風險的舊版 OAuth 2.0 流程，應該被廢除。它將使用者的憑證暴露給用戶端應用程式，不支持現代安全機制，如 MFA 或 SSO。我們強烈建議避免在你的應用程式中使用 ROPC 授權類型。如果你有依賴 ROPC 授權類型的舊版認證系統，請考慮遷移到更安全的 OAuth 2.0 流程，如授權碼流程或用戶端憑證流程。

聯繫我們，如果你需要幫助將安全的用戶驗證和授權服務整合到你的應用程式中，或從舊版的密碼驗證系統遷移到更安全的 OAuth 2.0 流程。我們隨時為你提供支援，幫助你建立安全和現代化的應用程式。

介紹#

ROPC 授權類型 vs. 授權碼流程#

ROPC 授權類型是如何運作的#

授權碼流程如何運作#

ROPC 授權類型的安全風險#

1. 使用者憑證暴露#

2. ROPC 不支持使用者同意#

3. ROPC 不支持多因素驗證#

ROPC 與現代應用程式不兼容#

1. ROPC 與 SSO 不兼容#

2. ROPC 與聯合身份不兼容#

結論#

介紹#

ROPC 授權類型 vs. 授權碼流程#

ROPC 授權類型是如何運作的#

授權碼流程如何運作#

ROPC 授權類型的安全風險#

1. 使用者憑證暴露#

2. ROPC 不支持使用者同意#

3. ROPC 不支持多因素驗證#

ROPC 與現代應用程式不兼容#

1. ROPC 與 SSO 不兼容#

2. ROPC 與聯合身份不兼容#

結論#

介紹

ROPC 授權類型 vs. 授權碼流程

ROPC 授權類型是如何運作的

授權碼流程如何運作

ROPC 授權類型的安全風險

1. 使用者憑證暴露

2. ROPC 不支持使用者同意

3. ROPC 不支持多因素驗證

ROPC 與現代應用程式不兼容

1. ROPC 與 SSO 不兼容

2. ROPC 與聯合身份不兼容

結論

介紹

ROPC 授權類型 vs. 授權碼流程

ROPC 授權類型是如何運作的

授權碼流程如何運作

ROPC 授權類型的安全風險

1. 使用者憑證暴露

2. ROPC 不支持使用者同意

3. ROPC 不支持多因素驗證

ROPC 與現代應用程式不兼容

1. ROPC 與 SSO 不兼容

2. ROPC 與聯合身份不兼容

結論