簡析認證加授權如何使API更安全

*本文原創作者：yuegui_2004，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載

近期在公司推廣實施安全開發生命週期流程（SDL），基於目前業務的發展，有很多以API形式提供的資料訪問介面，為此專門對所有系統的API介面進行了一次梳理，在梳理過程中發現了部分介面存在的安全隱患，包括未授權訪問、資料校驗不完整、訪問敏感資料等問題。因此在這裡針對API可能帶來的安全問題聽過一些安全解決措施，大家一起交流學習。

隨著業務開放性的發展趨勢，為了應對快速發展的業務及靈活多變的程式需求，API（Application Programming Interface）在程式中的應用顯得愈發重要，API為外部業務對接、系統間的呼叫提供了靈活性和創新性。然而與此同時，隨之而來的則是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安全這方面的經驗和問題。

*本文原創作者：yuegui_2004，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載