我有一個使用 angular-auth-oidc-client 與 KeyCloak 服務器集成的 Angular 應用程式
我使用 PKCE 流程并從 Keycloak 服務器（OIDC 提供程式）獲取 id 令牌、訪問令牌和重繪 令牌。我不需要重繪 令牌，但 Keycloak 服務器似乎總是回傳它，即使范圍不使用“offline_access”。
默認情況下，OAuth 庫將所有??令牌存盤在會話存盤中。我撰寫了一個自定義存盤來忽略重繪 令牌，而不是將它們存盤在會話存盤中。
我在互聯網上讀到會話存盤不是完全安全的存盤，存盤的 XSS 攻擊可以檢索令牌。然而，Stored XSS 的緩解措施是使用標準框架，如我正在使用的 Angular。
假設存盤型 XSS 漏洞幾乎是不可能的情況，上述解決方案是否安全，其中我使用會話存盤中的訪問令牌來呼叫我的后端 API。
uj5u.com熱心網友回復：
SPA 的當前最佳實踐
使用訪問令牌時有更多的攻擊向量和未知數，當前的最佳實踐是使用 aBackend for Frontend以便HTTP Only SameSite=strict在瀏覽器中只使用 cookie。
也可以通過實用程式 API 發出 cookie，以避免影響您的整體 SPA 架構。在 Curity，我們的SPA 最佳實踐對此有更多資訊，盡管這是一個棘手的流程。
還有一個指向更深入討論威脅的白皮書的鏈接。在某種程度上，您選擇的解決方案將取決于您的資料的價值。對于中高安全性資料解決方案，目前首選僅 cookie 解決方案。
多個 SPA 和單點登錄
SSO 是身份提供者會話 cookie 的屬性，也是應用程式是否使用 OpenID Connect 引數，例如prompt=login和max_age。因此，多個 SPA 仍然可以使用 BFF 解決方案實作 SSO，每個應用程式都被發行不同的令牌。
多個 SPA 在呼叫 API 時必須使用隔離的 cookie，因此需要使用不同的 API 路由。這增加了復雜性，所以我理解這些擔憂。我也喜歡oidc-client等較舊的純 Javascript 解決方案的簡單性。
攻擊向量
其中包括通過 fetch API 的猴子補丁捕獲飛行到 API 的令牌、攻擊者旋轉獲取令牌的隱藏 iframe 或瀏覽器擴展的攔截操作。
如果令牌以某種方式被攔截，它們可能會被發送出瀏覽器。內容安全策略應該降低這種風險，但用戶或插件可以禁用它們。該視頻討論了威脅并且非常有趣。
洞察力
這是最大的因素之一——如果您必須向客戶、利益相關者或 PEN 測驗人員解釋您的安全性。如果您遵循 BCP，這些對話會更容易。否則，在某些領域，您可能會面臨棘手的問題。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/469042.html