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

[[251397]]

一、安全的第一原則

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

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

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

二、獲取令牌的API密鑰

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

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

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

針對(duì)上述缺點(diǎn)，OAuth應(yīng)運(yùn)而生，其特點(diǎn)如下：

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

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

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

四、Opaque與JWT

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

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

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

OAuth的授權(quán)類型決定了客戶端將如何獲取令牌。這在我們自己團(tuán)隊(duì)內(nèi)部，常被戲稱為“OAuth舞蹈”。因?yàn)殡m然在OAuth世界中，有著很多種“跳舞形式”，但是有一種您必須記住，那就是：授權(quán)代碼。雖說在某些情況下，其他授權(quán)類型可能也非常實(shí)用，但授權(quán)代碼類型則是包括Web應(yīng)用、原生應(yīng)用、和移動(dò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)。

特別對(duì)于公共客戶端和移動(dòng)應(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提供者，請(qǐng)確保自己的OAuth服務(wù)器能夠支持此選項(xiàng)。

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

六、令牌管理的建議

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. 徹底驗(yàn)證JWT

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

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

7. 不要將令牌存儲(chǔ)在本地，請(qǐng)使用安全的Cookie

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

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

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

9. 使用專用的瀏覽器視圖來請(qǐng)求信息

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

七、結(jié)論

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

參考

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

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

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