怎樣使WEB API更安全？

隨著業務開放性的發展趨勢，為了應對快速發展的業務及靈活多變的程序需求，API（Application Programming Interface）在程序中的應用顯得愈發重要，WEB API為外部業務對接、系統間的調用提供了靈活性和創新性。然而與此同時，隨之而來的則是API應用帶來的一系列安全問題，

一個安全的API僅可對其用戶、應用程序、以及消費它的服務可見，以此確保信息的保密性；除此之外，同時要保證客戶端和服務端間交互的信息沒有被第三方篡改，以此保證信息的完整性。要滿足信息的保密性和完整性，對調用方和終端用戶進行身份認證是前提條件。

身份驗證可以說是安全界的核心。API創建者需要有能力識別消費API的用戶、應用以及調用API的服務，那麼就需要有一個身份存儲庫來識別並確認用戶和應用的身份有效性。身份存儲庫目前最常用的解決方案就是LDAP 服務，而活動目錄（AD）是目前對LDAP最流行的一種實現。LDAP服務主要存儲用戶名、密碼、數字證書以及其他用戶相關的身份信息和用戶所屬機構組織信息，應用的身份信息同樣可以存儲在這裡。身份提供者（IP）是專用於管理與身份存儲庫的交互以用於身份驗證和授權的軟件，APP可以將身份驗證及授權的工作交由身份提供者處理，這是一種更加安全和可取的方法。

當調用者使用應用ID和用戶名調用你的API時，API需要有能力識別調用者提供的信息的有效性，這種有效性驗證主要是通過驗證共享的秘密信息來完成的。當你的API作為身份提供者時，通常會傳遞同樣的身份認證信息到LDAP服務進行驗證。下面介紹幾種常用的API身份驗證的方法。

第一種就是用戶名密碼方式，這也是最簡單的一種認證方式。系統間身份認證使用這種方式實現時，身份認證使用的密碼可能會在多個API間進行共享。用戶名密碼身份認證方式並不推薦使用，主要是基於兩方面的考慮：首先是由於密碼的可猜測性，密碼是人為生成，安全性較低；其次是密碼的維護工作也存在困難，例如修改某個API進行身份認證的密碼，那麼所有相關聯的應用都會受到影響。

第二種是多因素認證方式（MFA），即在用戶知道什麼的前提下，進一步通過用戶有什麼進行身份驗證，通過用戶獲取到的一次性token來進一步驗證用戶身份憑證。這個token可以是MFA服務提供者發送的短信，也可以是數字key，目前已經有成熟的第三方數字key服務提供商，開源的有Google Authenticator、FreeOTP，商用的則有RSASecurID。

第三種方式是基於Token的身份認證憑證，是對用戶名密碼安全性的補充，為用戶名密碼的認證和授權提供了一種更加安全的方式。身份提供者基於用戶名密碼的身份憑證生成一個獨立的token，後續與應用的交互，只需要將該token傳遞給應用，因此通過網絡來回切換的用戶名/密碼憑證大幅減少。同時，token被設置了過期時間並且可以被撤銷，從而保證了token使用上的安全性。更重要的是，針對每個應用都生成對應的獨立token，當撤銷或者失效某一個token時，其他應用仍可以正常使用自己的token，無需再次進行用戶名密碼認證。

如下圖所示，用戶Gary登錄應用，應用驗證其用戶名密碼身份信息，並向身份提供者申請token，身份提供者在身份存儲庫中驗證Gary的身份有效性，驗證通過後，身份提供者嚮應用返回token，接下來應用就可以使用這個token作為調用API的身份憑證。這也是目前網絡認證協議Kerberos的實現基本原理。

接下來要介紹的是聯合身份認證機制。基於令牌的身份認證方式允許將令牌的發佈與其驗證分開，從而促進身份管理的集中化。API的開發者只需要關心用戶在調用API時的驗證邏輯，不需要關心具體的身份認證邏輯，這部分是由集中式身份提供者完成的，API只需要在請求中帶上token，然後由集中式身份提供者完成對token有效性的驗證，如果生成的token有權限發起這次請求，則API將被允許調用。身份提供者能夠對用戶、應用及APP的身份進行識別和認證，是基於它們的身份信息和共享密碼都存儲在身份存儲庫中。但是，你的API不會始終暴露給身份提供者能識別的應用和用戶，如果你希望將你的API暴露給外部用戶控制的應用，外部用戶可能來自於其他公司或者公司內部的其他業務部門，這時候該如何控制API的安全性呢？尤其是對於大公司而言，他們有很多的安全上下文，每個安全上下文都包含有獨立的身份存儲庫和身份提供者，此時，聯合身份機制應運而生，聯合身份提供者能夠對來自不同安全上下文的用戶進行認證和授權。

聯合身份認證機制的流程如下圖所示，與普通的基於token的身份認證流程類似，但流程中增加了物流API和物流系統身份提供者兩個角色，應用利用訂單系統身份提供者返回的有效token申請訪問物流API，物流API向物流系統身份提供者申請驗證token有效性，但它並不知道此token是否有效，必須向訂單系統身份提供者申請驗證此token，而不是在物流身份存儲庫中檢索此token的信息，這裡的訂單系統身份提供者和物流系統身份提供者就是聯合身份提供者。

身份認證完成之後，就需要根據用戶的身份對其進行授權，其權限的大小由其身份決定。下面就介紹幾種在API安全中使用的授權模式。

第一種是最常用的基於角色的訪問控制模型。每個企業或組織的員工都會根據其業務職責劃分成不同的部門或組。那麼這些組織內的員工就根據其分組界定其權限。分組信息就可以應用在於應用交互中，根據應用的授權及在應用中設置不同分組的訪問規則來限制用戶的訪問，用戶所在分組決定其在應用中的角色權限。輕量級目錄訪問協議（LDAP）服務正是利用了分組的概念。身份提供者負責從身份存儲庫中檢索分組信息，角色則是應用對訪問控制權限的具體定義，用戶則可以採用應用定義的多個角色。

基於角色的訪問控制是一種非常簡單的訪問控制機制。應用不需要維護每個用戶能訪問的數據和功能，只需要通過角色將數據和功能訪問權限抽象化，而只需要根據用戶的角色分配不同的訪問權限。

第二種授權方式是基於屬性的訪問控制模型（ABAC）。不同於基於靜態角色訪問控制方式，基於屬性的訪問控制旨在調用API時根據用戶的環境信息動態分配其訪問控制權限，環境信息包括如訪問時間、角色、API的地理位置、應用的地理位置以及其他決定訪問程度的條件的組合信息。可擴展的訪問控制標識語言（XACML）是一種基於XML的開放標準語言，是一種用於決定請求/響應的通用訪問控制策略語言和執行授權策略的框架，可定義API調用時訪問控制規則，這種規則可以在不同API調用時進行動態變換，是一種典型的ABAC環境下的策略描述語言。

第三種是基於Oauth 2.0的代理訪問控制方式。基於HTTP的OAuth 2.0框架允許應用程序代表自己或代表用戶獲取對API資源的訪問權限。 因此，它允許用戶將訪問控制委派給第三方應用程序。 為此，你的API接口必須與OAuth 2.0授權服務器協作，檢查每次請求訪問token時，都經過授權服務器的校驗。授權服務器則向請求方返回響應，指明訪問token是否有效，是否是由OAuth提供者生成並且未過期的，同時校驗該token能訪問的範圍。

提到聯合身份認證機制，就不得不提到安全斷言標記語言（SAML）。安全斷言標記語言（SAML）是一種行業標準，已成為企業級身份聯合的事實標準。它允許身份提供者以標準方式將有關用戶的身份驗證和授權信息傳遞給服務提供者。SAML斷言可以由一個安全上下文中的身份提供者發佈，並被另一個安全上下文中的身份提供者所理解。SAML斷言通常傳達有關用戶的信息給另一個身份提供者，包括用戶所屬組織，以及斷言的到期時間，無需提供密碼信息，驗證斷言有效性的身份提供者必須與發佈斷言的身份提供者建立信任關係。在企業內使用SAML的主要場景就是單點登錄（SSO），用戶無需為每個需要登陸的應用單獨維護一套身份信息，僅僅需要在服務提供者處註冊登陸一次即可暢通無阻的訪問其他應用。

這裡介紹一種實現SSO身份認證常用的協議—OpenID Connect。OpenID Connect構建於OAuth 2.0之上，提供聯合身份機制來保護你的API。它不但能支持原生和移動應用程序，同樣適用於企業級應用，它基於JSON/REST的協議使其應用更加簡便快捷，是一種在企業內部實現單點登錄更加輕量級的解決方案。不同於Oauth 2.0的訪問token，OpenIDConnect使用JWT ID token，token中包含已經身份驗證通過的用戶的標準格式信息。API可以通過調用身份提供者上的用戶信息端點來確定訪問控制策略，以驗證用戶是否屬於某個角色。 與SAML斷言一樣，JWT ID令牌經過數字簽名，因此聯合身份提供者可以根據與發佈它們的身份提供者的信任關係來決定是否接受此token。

認證和授權是API安全的前提，一個安全的API應該有能力識別調用它的系統和終端用戶的身份，本文介紹了幾種認證和授權機制，來加強API的安全性，在實際應用場景中，可以根據具體情況採用不同的實現方式，也希望大家能夠更多交流API安全這方面的經驗和問題。

以上，是從WEB API功能設計的角度進行的探討，但如果API接口系統是已建成、在使用中的。又該如何提升級安全性呢？方法是：進行WEB安全改造，說的簡單點，即：部署具有WEB API防護能力的WAF，比如

閱讀更多 WangLiwen 的文章

關鍵字: 軟件 業務 開放性