【51CTO.com快譯】如今，無論是基于Web的應(yīng)用、還是本地原生的各種程序，都需要通過后端的API來實現(xiàn)資源的訪問保護(hù)。要想得到API的授權(quán)，各種訪問請求就必須包含相應(yīng)的訪問令牌或密鑰。本文將向API提供者和應(yīng)用程序開發(fā)人員重點介紹，我們在管理訪問令牌中的各種最佳安全實踐。

[[251397]]

一、安全的第一原則

在我們處置安全性時，首先要考慮的一條原則是：不可相信任何人。如果您是一名API提供者，您不能保證正在調(diào)用API的應(yīng)用程序就是您所預(yù)期的那個，您無法確信收到的令牌沒有被盜，或者客戶端和服務(wù)器之間的通信沒有被截獲。特別是在客戶端，您無法確認(rèn)應(yīng)用程序沒有被反編譯過(而且已暴露了內(nèi)嵌在應(yīng)用程序之中的密碼)。當(dāng)然，您也無法確定應(yīng)用程序的存儲不會受到跨站腳本式攻擊(詳見https://www.owasp.org/index.php/Cross-site_Scripting_(XSS))，更無法保證您的用戶沒有在被欺騙的狀態(tài)下進(jìn)行偽造請求的提交(詳見https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF))。可見，您必須采取適當(dāng)?shù)拇胧瑏戆踩孬@取、存儲和管理那些調(diào)用后端API所需的安全令牌。

另外，您也許會認(rèn)為：只要不被公開發(fā)布出去，自己的API就是安全的。您甚至還可能認(rèn)為：由于API僅被自己的企業(yè)應(yīng)用程序所用到，它們理所當(dāng)然是私有的?？墒獠恢绻鼈兛梢栽谀硞€移動應(yīng)用中被調(diào)用，那么它們就置于了公網(wǎng)之上。也就是說，任何暴露在企業(yè)網(wǎng)絡(luò)外部的API，都應(yīng)被視為公開的(詳見

https://www.42crunch.com/a10-owasp/)。

二、獲取令牌的API密鑰

在使用API​​時，我們通常有兩種選擇：一種是將一段靜態(tài)信息與API調(diào)用同時進(jìn)行傳遞;另一種是在調(diào)用API之前，動態(tài)地獲取一段信息。這段信息通常被稱為訪問令牌或API密鑰。由于一些歷史遺留的問題，BasicAuth(譯者注：BasicAuth認(rèn)證方式是在每次請求API時，僅提供用戶的username和password)仍在被某些API所使用著，但實際上，它已經(jīng)不再是主流的認(rèn)證解決方案了。

因此，在設(shè)計API的安全性方面，您必須謹(jǐn)慎地考慮到API使用者將如何去訪問它。而在考慮所采用的安全措施時，您需要全面地分析各種風(fēng)險因素。顯然，我們對于咨詢天氣數(shù)據(jù)的API、與銀行支付類型的API的保護(hù)，會采用截然不同控制措施。

雖然API​​密鑰能夠被開發(fā)人員輕松地實現(xiàn)和使用，但它的安全級別不及于使用訪問令牌，通過雙因素身份驗證，來正確地識別出客戶端應(yīng)用身份的方式。此外，API密鑰并不攜帶任何有關(guān)用戶的信息，因此它不能被后端級別(backend level)用來決定API使用者可以進(jìn)行哪些調(diào)用操作。再者，除非API提供者主動撤銷，否則API密鑰永遠(yuǎn)不會過期。

針對上述缺點，OAuth應(yīng)運而生，其特點如下：

• 訪問資源的應(yīng)用程序是已知的(用到了客戶端應(yīng)用程序的信任憑據(jù))。
• API提供者可以通過定義范圍，來限制對某些操作的訪問(您可以GET到某個目錄條目，但是就算使用的是有效的令牌，您仍然無法PUT新的目錄條目)。
• 令牌具有有限的生命周期。

三、讓我們從一些術(shù)語開始

OAuth所用到的術(shù)語有時會讓人感到費解，讓我們通過下面的表格，來了解一些與開發(fā)有關(guān)的重點術(shù)語。

四、Opaque與JWT

由于OAuth并不限制使用訪問令牌的格式，因此按照OAuth服務(wù)器的實現(xiàn)規(guī)則，訪問令牌既可以是Opaque(通常是一條不帶有任何有用信息的長字符串)，也可以是一種JSON Web令牌(JWT)。

JWT的優(yōu)勢在于它能夠包含各種聲明、或是有關(guān)用戶的信息，而后端服務(wù)則可以籍此來進(jìn)行各種業(yè)務(wù)邏輯的決策。

五、學(xué)習(xí)“OAuth舞蹈”

OAuth的授權(quán)類型決定了客戶端將如何獲取令牌。這在我們自己團隊內(nèi)部，常被戲稱為“OAuth舞蹈”。因為雖然在OAuth世界中，有著很多種“跳舞形式”，但是有一種您必須記住，那就是：授權(quán)代碼。雖說在某些情況下，其他授權(quán)類型可能也非常實用，但授權(quán)代碼類型則是包括Web應(yīng)用、原生應(yīng)用、和移動應(yīng)用在內(nèi)的所有應(yīng)用程序，獲取訪問令牌的推薦方法(詳見

http://www.pingidentity.com/en/company/blog/posts/2018/securely-using-oidc-authorization-code-flow-public-client-single-page-apps.html)。

特別對于公共客戶端和移動應(yīng)用而言，我們建議采取額外的安全措施，來防止授權(quán)代碼被盜。此類安全層往往被稱為“代碼交換證據(jù)密鑰”(Proof Key for Code Exchange，PKCE)標(biāo)準(zhǔn)。您可以通過鏈接：https://tools.ietf.org/html/rfc7636，了解更多有關(guān)PKCE，以及如何使用它的信息。如果您是API提供者，請確保自己的OAuth服務(wù)器能夠支持此選項。

同時，您應(yīng)該特別注意資源所有者的密碼授權(quán)。雖然它實現(xiàn)起來最為簡單，但是由于其核心要求是在客戶端與服務(wù)器間建立信任關(guān)系，因此您可能永遠(yuǎn)也用不到它。

六、令牌管理的建議

1. 注意OAuth應(yīng)用的憑據(jù)泄漏

您會把應(yīng)用程序的代碼存儲在GitHub中嗎?您的OAuth應(yīng)用憑據(jù)是否也會存儲在那兒，特別是客戶端的密鑰?可您知道嗎?這已經(jīng)成為了當(dāng)今信任憑據(jù)泄密的頭號來源。只要這些憑據(jù)被盜，任何人都可以偽裝成您的身份，發(fā)起中間人攻擊。因此，如果您一旦發(fā)現(xiàn)憑據(jù)可能已被泄露，那就請立即重新生成新的憑據(jù)。

此外，請永遠(yuǎn)不要將客戶端的密碼放置在分布式代碼之中，例如：通過應(yīng)用軟件商店、或客戶端JavaScript下載的各類應(yīng)用里。

2. 不要在應(yīng)用程序中對令牌進(jìn)行硬編碼

千萬不要為了圖省事，而簡化獲取令牌的代碼，并將其長時間存儲在自己的應(yīng)用程序之中。

3. 像處置密碼一樣去處置令牌

由于任何掌握了令牌和API密鑰的人都能訪問到對應(yīng)的資源。因此，我們需要像處置各種密碼那樣,去認(rèn)真地處理和保存各種令牌。

4. OAuth并非是身份驗證協(xié)議

OAuth處理的是對資源訪問權(quán)限的委派，因此它并非是一種身份驗證協(xié)議(盡管名稱很像)。我們可以將令牌看作酒店房間的鑰匙。您需要讓自己的身份得以驗證，方可獲得酒店鑰匙。但是，一旦您手中已有了鑰匙，它就不能再去驗證您是誰了。最近發(fā)生的一些用戶信息泄露事件證明了，API提供者不可單一地將是否持有令牌作為身份驗證的依據(jù)。

另外，我建議您也參考一下OpenID Connect(OIDC，詳見https://www.oauth.com/oauth2-servers/openid-connect/)。不過，它只是一種補充性的規(guī)范，而并非是想在OAuth之上實現(xiàn)身份驗證的功能。OIDC允許用戶與應(yīng)用程序共享其配置文件里的某些信息，但并不是他們的信任憑據(jù)。

5. 注意您在JWT中存儲的內(nèi)容和誰有權(quán)限訪問

JWT能夠以各種聲明的形式存儲大量的信息，如果這些信息被捕獲，攻擊者就能夠輕松地解析出具體的內(nèi)容(除非它們被加密了)。因此，如果您想使用JWT向后端服務(wù)傳遞有用的信息，那么您可以采用如下的實現(xiàn)方法：

• 在客戶端和后端之間，僅使用Opaque字符串、或是基本的JWT。
• 在后端，驗證某個請求、并注入一個新的JWT，它的有效負(fù)載中可包含一個能夠被下游用到的聲明。許多API安全網(wǎng)關(guān)都能以“開箱即用”的方式提供該功能。

如果想在整個流程中使用相同的令牌，并且讓該令牌攜帶一些敏感的信息，那么請您務(wù)必加密該令牌的有效負(fù)載。也就是說，請永遠(yuǎn)不要使用JWT來攜帶用戶的信任憑據(jù)，例如：密碼!

6. 徹底驗證JWT

當(dāng)您在服務(wù)器端收到JWT時，請務(wù)必徹底驗證其內(nèi)容。需要特別注意的是：您應(yīng)該直接拒絕任何不符合預(yù)期的簽名算法、使用了弱簽名算法、和使用了弱非對稱/對稱密鑰進(jìn)行簽名的JWT。此外，您必須驗證所有的聲明、到期日期、發(fā)布者和受用者。

在市面上，有些庫和工具可以直接為您執(zhí)行該操作、有些則需要您事先進(jìn)行適當(dāng)?shù)呐渲谩⒍硪恍┛赡苤荒茏龅讲糠謾z查。因此，具體該使用哪一種方式，還取決于您所使用到的庫。

7. 不要將令牌存儲在本地，請使用安全的Cookie

任何在瀏覽器上的本地存儲、和會話存儲，都有可能被JavaScript所讀取到?？梢?，用此方式來存儲令牌之類的敏感信息是極不安全的。因此，您可以使用安全的Cookie、帶httpOnly的標(biāo)識、以及CSRF等措施，來防止令牌被盜。

8. 始終通過HTTPS和請求正文(Request Body)的方式傳輸令牌

通過這種方法，您可以限制令牌在傳輸過程中被捕獲，或是被寫到代理日志、以及服務(wù)器日志之中的風(fēng)險。您還應(yīng)該確保只使用TLS的1.2/1.3版本，以及在頒發(fā)和驗證令牌的各個環(huán)境中，使用最安全的密碼套件。

9. 使用專用的瀏覽器視圖來請求信息

許多應(yīng)用程序都用到了嵌入式的用戶代理，但是，由于它屏蔽了用戶去驗證與之通信的網(wǎng)站真?zhèn)?，因此，我們實際上應(yīng)當(dāng)避免使用這樣的代理。此外，應(yīng)用程序應(yīng)當(dāng)能夠完全掌握用戶所輸入的憑據(jù)。正如那些OAuth原生應(yīng)用所采用的最佳做法那樣，一些API提供者會采取強安全措施，來應(yīng)對此類問題。

七、結(jié)論

訪問令牌是如今各種應(yīng)用程序的實現(xiàn)基礎(chǔ)，因此我們在處置的時候一定要倍加小心。如果您是一名后端開發(fā)者，您必須確保提供適當(dāng)?shù)氖跈?quán)類型，以獲取訪問令牌;同時還應(yīng)該支持移動應(yīng)用的PKCE;以及對JWT進(jìn)行全面驗證。而如果您是一位前端開發(fā)者，則必須能夠管控JWT的存儲、并保護(hù)應(yīng)用的各種信任憑據(jù)。

參考

• PKCE(https://tools.ietf.org/html/rfc7636)
• JWT的驗證實踐(https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-03)
• 原生應(yīng)用程序的最佳實踐OAuth(https://tls.mbed.org/)

原文標(biāo)題：Security Best Practices for Managing API Access Tokens，作者：Isabelle Mauny

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】