繁體中文（香港）

oauth
security
oidc
authentication

為什麼你應該棄用資源擁有者密碼憑證 (ROPC) 授權類型

資源擁有者密碼憑證 (ROPC) 授權類型是一個過時的 OAuth 2.0 流程，會帶來安全風險，應該棄用。在這篇文章中，我們將說明為什麼你應該避免在應用程式中使用 ROPC。

Simeng

Developer

4/24/2024

Stop wasting weeks on user auth

Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.

Get started

介紹

資源擁有者密碼憑證 (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 授權類型實現基於挑戰的身份驗證機制，例如 SMS OTP、email OTP 或 WebAuthn。

ROPC 與現代應用程式不兼容

ROPC 授權類型設計用於支持無法支持現代 IAM 系統單點登錄 (SSO) 或聯合身份的傳統應用程式。

1. ROPC 與 SSO 不兼容

單點登錄 (SSO) 是一種現代身份驗證架構，允許用戶只需登錄一次即可無縫訪問多個應用程式。

在 SSO 架構中，一個集中式 IdP 發揮著至關重要的作用。它管理用戶的身份驗證會話並向用戶端應用程式發送令牌。用戶端應用程式無需直接收集用戶的憑證，並且用戶的憑證在 IdP 中保密。

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

2. ROPC 與聯合身份不兼容

類似於 SSO 架構，聯合身份允許用戶使用其現有身份訪問多個第三方應用程式。用戶可以將多個社交賬號如 Google、Facebook 或 Twitter 連接到一個集中式 IdP，並使用這些社交賬號進行用戶端應用程式的身份驗證。所有聯合身份由 IdP 管理，並且用戶端應用程式對用戶的身份驗證詳情不會知道。

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

結論

資源擁有者密碼憑證 (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 與聯合身份不兼容

結論