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

[[251397]]

一、安全的第一原則

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

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

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

二、獲取令牌的API密鑰

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

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

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

針對上述缺點，OAuth應運而生，其特點如下：

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

三、讓我們從一些術語開始

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

四、Opaque與JWT

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

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

五、學習“OAuth舞蹈”

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

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

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

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

六、令牌管理的建議

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

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

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

2. 不要在應用程序中對令牌進行硬編碼

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

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

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

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允許用戶與應用程序共享其配置文件里的某些信息，但并不是他們的信任憑據(jù)。

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

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

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

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

6. 徹底驗證JWT

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

在市面上，有些庫和工具可以直接為您執(zhí)行該操作、有些則需要您事先進行適當?shù)呐渲?、而另一些可能只能做到部分檢查。因此，具體該使用哪一種方式，還取決于您所使用到的庫。

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

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

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

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

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

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

七、結(jié)論

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

參考

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

原文標題：Security Best Practices for Managing API Access Tokens，作者：Isabelle Mauny

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