采用OAuth 2.0授權框架

實施OAuth 2.0需要集成授權服務器，用于頒發訪問令牌。這一組件由安全專家設計，可實現高級安全功能。然而，不同的API、客戶端和用戶場景需要選擇最優的OAuth 2.0特性，這需要專業的洞察力。以下是Curity公司推薦的最佳實踐方案。

B2B API客戶端需提供持有證明

在為商業伙伴提供API時，采用基于標準的“持有證明訪問令牌”是一種簡單而有效的方法。該方法通過底層安全通信通道，將訪問令牌與TLS客戶端證書綁定。商業伙伴的應用程序在后續的所有API請求中，都需要同時提交訪問令牌和對應的TLS客戶端證書。

實際案例

商業伙伴可以選擇自行生成客戶端證書，或者向API提供方申請證書。隨后，這些證書會被配置到企業的授權服務器中。為簡化集成流程，可以通過正向或反向代理終止雙向TLS連接，從而避免對客戶端或API代碼的影響。

瀏覽器API客戶端使用最強Cookie

對于基于瀏覽器的應用，瀏覽器本身就是終端客戶端。由于為每個終端用戶頒發客戶端證書并不實際，因此證書綁定訪問令牌的方案可能無法適用。然而，企業仍需采取措施防范令牌和數據的竊取。

瀏覽器應用主要面臨跨站腳本（XSS）攻擊的威脅，惡意代碼可能竊取瀏覽器中的令牌和數據。為了降低風險，建議避免在瀏覽器中存儲令牌。最佳方案是采用前端后端（BFF）模式，由BFF向瀏覽器頒發具備HTTP-only, SameSite=strict屬性的安全Cookie，而不是直接使用令牌。雖然無法完全消除XSS威脅，但這種方法可以顯著降低其影響，并防止令牌泄露。

令牌處理模式

BFF還可以選擇使用客戶端證書接收證書綁定訪問令牌。盡管瀏覽器請求本身無法提供持有證明，但通過BFF可以實現更全面的防護。

移動API客戶端采用認證機制

傳統的OAuth安全移動應用通常遵循《OAuth 2.0 for Native Apps》標準，通過系統瀏覽器完成用戶認證，然后將授權碼轉發給應用以換取令牌。然而，與瀏覽器應用類似，為終端用戶設備安裝客戶端證書以實現證書綁定令牌的方案通常不可行。

移動應用屬于公共客戶端，可能會遭到惡意應用的仿冒攻擊，從而竊取令牌。為緩解這一風險，建議使用HTTPS重定向URI和代碼交換證明密鑰（PKCE）。盡管如此，刷新令牌仍然可能被竊取，進而導致攻擊者獲取新的訪問令牌。

強化移動流程

自2017年RFC 8252發布以來，移動設備的能力顯著提升。如今，所有移動設備都配備了硬件級密鑰，可以在認證前通過數字簽名驗證客戶端的真實性。利用設備密鑰，可以進一步強化移動認證流程，防止仿冒并保護刷新令牌。

實施零信任后端

在零信任架構下，API需要對所有請求進行業務授權，并通過訪問令牌中的安全值來實現這一目標。無論調用方來自內網還是外網，API都應執行嚴格的驗證。

關鍵技術

《實施零信任API》一文詳細介紹了驗證訪問令牌、基于聲明的授權以及在多API間安全共享身份值的關鍵技術。此外，云原生平臺提供了額外的基礎設施安全層。例如，SPIFFE方案允許每個后端組件獲取工作負載身份及配套密鑰對，從而要求后端API和數據庫通過雙向TLS連接驗證工作負載身份。這種機制確保了內部請求的機密性，并限制了合法調用方的范圍。

添加密碼學支持的用戶認證

即使API和客戶端實施了強安全措施，賬戶劫持仍然是一個重大威脅。傳統的密碼登錄方式存在多種隱患，例如服務器漏洞可能導致大量密碼泄露、密碼易受釣魚攻擊，以及在移動端的用戶體驗較差。

通行密鑰認證

2024年推薦增加“通行密鑰認證”作為登錄選項。該方案基于密碼學密鑰對，提供強認證，同時簡化用戶體驗。用戶可以為賬戶注冊多個通行密鑰，并通過郵箱驗證的賬戶恢復機制，在設備丟失的情況下恢復訪問。

強認證需要與可靠的API訪問控制相結合。OAuth客戶端不應直接實現認證，而應由授權服務器協調認證流程。用戶登錄后，授權服務器會向客戶端頒發最小權限的訪問令牌，從而限制其對API的訪問范圍。

結論

設計最佳的安全防護方案需要深入理解API、客戶端及其運行環境。某些連接類型可以采用持有證明機制，而其他場景則需要根據實際需求選擇不同的最佳實踐。

通過投資構建現代化令牌架構的組件，企業可以有效管理安全風險。一旦掌握了基礎模塊，相同的安全模式可以復用于多種場景，包括保護軟件供應鏈等關鍵組件。

正確實施這些方案可以幫助企業構建面向未來的平臺：復雜的安全代碼被外部化，業務組件只需簡單代碼即可實現安全；通過升級授權服務器，企業可以持續獲得最新的安全能力支持。這種設計不僅能夠擴展到大量API及其客戶端，還能助力企業的數字化方案實現安全增長。

原文鏈接: https://curity.io/blog/protect-against-token-and-credential-theft-in-2024/