使用 Apache APISIX 進行集中式身份認證及進階玩法
作者朱欣欣，開源愛好者，Apache APISIX committer。
個人 Github 主頁：https://github.com/starsz
身份認證在日常生活當中是非常常見的一項功能，大家平時基本都會接觸到。比如用支付寶消費時的人臉識別確認、公司上班下班時的指紋 / 面部打卡以及網站上進行賬號密碼登錄操作等，其實都是身份認證的場景體現。
如上圖，Jack 通過賬號密碼請求服務端應用，服務端應用中需要有一個專門用做身份認證的模塊來處理這部分的邏輯。請求處理完畢子後，如果使用 JWT Token 認證方式，服務器會反饋一個 Token 去標識這個用戶爲 Jack。如果登錄過程中賬號密碼輸入錯誤，就會導致身份認證失敗。這個場景大家肯定都非常熟悉，這裏就不做展開舉例了。
網絡身份認證的意義在哪裏？
安全性
身份認證確保了後端服務的安全性，避免了未經授權的訪問，從而確保數據的安全性。比如防止某些黑客攻擊，以及一些惡意調用，這些都可以通過身份認證進行阻攔。
實用性
從實用性的角度考慮，它可以更方便地記錄操作者或調用方。比如上班打卡其實就是通過記錄「誰進行了這項操作」來統計員工上班信息。其次它可以記錄訪問頻率及訪問頻次。例如記錄某用戶在最近幾分鐘中發起請求的頻率和頻次，可以判斷這個用戶活躍程度，也可以判斷是否爲惡意攻擊等。
功能性
在功能層面，它通過識別身份可以對不同的身份進行不同權限的操作處理。比如在公司裏，你的身份權限無法使用某些頁面或服務。再細緻一點，對不同身份或者不同的 API 接口調用方做一些相關技術上的限制策略，如限流限速等，以此來達到根據不同的用戶（調用方）採取不同的功能限制。
使用 Apache APISIX 進行集中式身份認證優點
從傳統到新模式
如下圖所示，左側的圖爲我們展示了一種比較常見的傳統身份認證方法。每一個應用服務模塊去開發一個單獨的身份認證模塊，用來支持身份認證的一套流程處理。但當服務量多了之後，就會發現這些模塊的開發工作量都是非常巨大且重複的。
這種時候，我們可以通過把這部分的開發邏輯放置到 Apache APISIX 的網關來實現統一，減少開發量。
圖右所示，用戶或應用方直接去請求 Apache APISIX，然後 Apache APISIX 通過識別並認證通過後，會將鑑別的身份信息傳遞到上游應用服務。之後上游應用服務就可以從請求頭中讀到這部分信息，然後進行後續相關工作的處理。講完了大概流程，我們來詳細羅列下。
優點一：配置收斂，統一管理
如上圖是一張 APISIX-Dashboard 的界面截圖，可以看到路由、Consumer 等數據信息。這裏的 Consumer 可以理解爲一個應用方，比如可以爲應用專門去創建一個 Consumer 並配置相關的認證插件，例如 JWT、Basic-Auth 等插件。當有新的服務出現時，我們需要再創建一個 Consumer，然後將這部分配置信息給配置到第二個應用服務上。
通過集中式身份認證，可以將客戶配置進行收斂並統一管理，達到降低運維成本的效果。
優點二：插件豐富，減少開發
Apache APISIX 作爲一個 API 網關，目前已開啓與各種插件功能的適配合作，插件庫也比較豐富。目前已經可與大量身份認證相關的插件進行搭配處理，如下圖所示。
基礎認證插件比如 Key-Auth、Basic-Auth，他們是通過賬號密碼的方式進行認證。複雜一些的認證插件如 Hmac-Auth、JWT-Auth。如 Hmac-Auth 通過對請求信息做一些加密，生成一個簽名。當 API 調用方將這個簽名攜帶到 Apache APISIX 的網關 Apache APISIX 會以相同的算法計算簽名，只有當簽名方和應用調用方認證相同時才予以通過。
Authz-casbin 插件是目前 Apche APISIX 與 Casbin 社區正在進行合作開發的一個項目，它的應用原理是按照 Casbin 的規則，去處理一些基於角色的權限管控 (RBAC)，進行 ACL 相關操作。
其他則是一些通用認證協議和聯合第三方組件進行合作的認證協議，例如 OpenID-Connect 身份認證機制，以及 LDAP 認證等。
優點三：配置靈活，功能強大
功能強大該如何理解，就是 Apache APISIX 中可以針對每一個 Consumer （即調用方應用）去做不同級別的插件配置。
如上圖，我們創建了兩個消費者 Consumer A，Consumer B。我們將 Consumer A 應用到應用 1，則後續應用 1 的訪問將會開啓 Consumer A 的這部分插件，例如 IP 黑白名單，限制併發數量等。將 Consumer B 應用到應用 2 ，由於開啓了 http-log 插件，則應用 2 的訪問日誌將會通過 HTTP 的方式發送到日誌系統進行收集。
Apache APISIX 中身份認證的玩法
關於 Apache APISIX 身份認證的玩法，這裏爲大家提供三個階段的玩法推薦，大家僅作參考，也可以在這些基礎上，進行更深度的使用和應用。
初級：普通玩法
普通玩法推薦大家基於 Key-Auth、Basic-Auth、JWT- Auth 和 Hmac-Auth 進行，這些插件的使用需要與 Consumer 進行關聯使用。
步驟一：創建路由，配置身份認證插件
創建路由，配置上游爲 httpbin.org，同時開啓 basic-auth 插件。
步驟二：創建消費者，配置身份信息
創建消費者 foo。在消費者中，我們需要配置用戶的認證信息，例如 username 爲 foo，password 爲 bar。
步驟三：應用服務攜帶認證信息進行訪問
應用攜帶 username:foo , password: bar 訪問 Apache APISIX。Apache APISIX 通過認證，並將請求 Authorization 請求頭攜帶至上游 httpbin.org 。由於 httpbin.org 中 get 接口會將請求信息返回，因此我們可以在其中觀察到請求頭 Authorization。
中級：進階玩法
進階模式下，是使用 Apache APISIX 與 OpenID-Connect 插件進行對接第三方認證服務。OpenID-Connect 是一種認證機制，可以採用該認證機制對接用戶的用戶管理系統或者用戶管理服務，例如國內的 Authing 和騰訊雲，國外的 Okta 和 Auth0 等。
具體操作如下，這裏使用 Okta 雲服務舉例：
步驟一：創建 OpenID-Connect 應用
在 Okta 控制檯頁面創建一個支持 OpenID-Connect 的應用。
步驟二：創建路由，配置 OpenID-Connect 插件
創建路由，配置訪問的上游地址爲 httpbin.org，同時開啓 openid-connect 插件，將 Okta 應用的配置填寫到 openid-connect 插件中。
步驟三：用戶訪問時，會跳轉至登錄頁面。登錄完成後，上游應用獲取用戶信息
此時，當用戶訪問 Apache APISIX 時，會先重定向到 Okta 登錄頁面。此時需要在該頁面填寫 Okta 中已經存在的用戶的賬號密碼。登陸完成之後，Apache APISIX 會將本次認證的 Access-Token，ID-Token 攜帶至上游，同時將本次認證的用戶信息以 base64 的方式編碼至 Userinfo 請求頭，傳遞至上游。
高級：DIY 玩法
這裏提供的 DIY 玩法是利用了 Serverless 插件，這款插件功能豐富，玩法也非常多。大家如果有自己的使用玩法，也歡迎在社區內進行交流。
具體操作流程就是將自己的代碼片段通過 Serverless 插件上傳到 Apache APISIX，這個過程中 Serverless 插件支持動態配置和熱更新。
方式一：自定義判斷邏輯
通過請求頭、參數等相關信息，來進行一些判斷。通過這種做法，我們可以去實現自己的一些規則，比如說結合企業內部的一些認證，或者去寫一些自己的業務邏輯。
方式二：發起認證鑑權請求
通過 HTTP 庫發起一個 HTTP 請求，我們可以利用第三方服務做一些認證、鑑權相關事情，然後解析返回結果。通過這種方式，我們可以做的事情就可以擴展很多。比如對接 Redis 或數據庫，只要是通過 TCP 或 UDP 這種形式的，都可以通過 Serverless 插件進行嘗試。
配置上傳
完成自定義代碼片之後，我們創建路由，並將代碼片配置到 Serverless 插件。後面再通過訪問 Apache APISIX 獲取相應的信息反饋，測試插件是否生效。
參考閱讀：
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/8z-AsfJNRjJiOrkPCIFu5g