如何快速實現REST API集成以優化業務流程
當來自多渠道的請求到達 API 網關后，網關需要識別出這些調用方。為此，Apache APISIX 提出了 Consumer 概念，用來代表某類服務的調用方。
Consumer 對象需要配置認證插件進行使用，以最簡單的 key-auth 插件為例：
curl http://127.0.0.1:9180/apisix/admin/consumers -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
"username": "jack",
"plugins": {
"key-auth": {
"key": "auth-jack"
}
}以上配置表示當請求中攜帶指定的 key（auth-jack）時，當前請求將會與 jack 這個消費者進行關聯。可以看到，Consumer 上配置的認證插件實際上就是一個指定認證機制下的身份憑證，在?key-auth?插件中，key 即是標識某個消費者的憑證，類似的還有?basic-auth?插件的用戶名與密碼等等。
當我們通過 Consumer 將憑證信息與具體的消費者進行關聯后，還需要在相應的路由上開啟認證插件：
curl http://127.0.0.1:9180/apisix/admin/routes/orders -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
"uri": "/orders",
"plugins": {
"key-auth": {
"header": "Authorization"
}
}
}以上配置表示在?/orders?這個路由上開啟?key-auth?插件，驗證效果如下：
curl http://127.0.0.1:9080/orders -H 'Authorization: auth-jack' -i
HTTP/1.1 200 OK
...
curl http://127.0.0.1:9080/orders -H 'Authorization: wrong-key' -i
HTTP/1.1 401 Unauthorized
...
{"message":"Invalid API key in request"}當來自用戶的請求命中這條路由時，APISIX 會嘗試通過?Authorization?頭部拿到用戶提供的 Key。如果無法獲取或者獲取到的 Key 是不合法的，那么該請求將會被網關直接拒絕，從而保護上游服務。
可以看到以上兩種認證方式中，認證插件都處于整個體系中的核心地位，它的豐富度將直接影響著 API 網關用戶對于認證方式的選擇空間。
認證鑒權作為計算機世界從第一天起就存在的基礎機制，經過這么多年的迭代，已經發展成為一個非常多樣化的領域。而 APISIX 的插件機制極大地降低了實現各種認證方式的開發成本，以下是部分 APISIX 已經支持的主流認證方式。
Key Auth 是目前 APISIX 所支持的認證方式中，使用起來最簡單的。但?key-auth插件在實際環境中有著非常豐富的應用場景，例如：收費軟件中的 License、開放 API 平臺中的用于標識開發者的 token 等等，都可以非常輕松地使用?key-auth來實現。并且基于 APISIX 全動態的配置下發能力，Key 可以被迅速創建、吊銷，而且實時生效。
Basic Auth 是基于用戶名、密碼進行認證的方式，常用于網頁登錄場景，例如：網站的管理后臺需要管理員登錄后才可以使用，那么我們可以使用 Basic Auth 方式進行認證。
LDAP（Lightweight Directory Access Protocol）是一種基于X.500 標準的輕量級文件訪問協議，通過IP 協議提供訪問控制和維護分布式信息的目錄信息，借助于 LDAP ，運維人員可以細粒度地控制用戶對資源的訪問權限。通過 APISIX 的ldap-auth插件，可以輕松對接實現了 LDAP 協議的平臺，例如微軟的 Active Direcory，或者 Linux 平臺的 OpenLDAP Server，從而能夠精細化地控制 Consumer 對具體路由的訪問權限。
OpenID 是一個去中心化的網上身份認證系統。對于支持 OpenID 的網站，用戶不需要記住像用戶名和密碼這樣的傳統驗證標記。取而代之的是，他們只需要預先在一個作為 OpenID 身份提供者（identity provider, IdP）的網站上注冊賬號，而后就可以用這個賬號登錄所有對接了該提供者的應用，例如：可以通過知名的 Google 或者 Facebook 服務的賬號來認證我們自身系統的用戶。
針對 OIDC，APISIX 提供了 openid-connect 插件，可以用于對接支持了 OIDC 協議的認證服務。
當 APISIX 的標準認證插件無法滿足你當前需求時，或者當前系統中已經部署了專門的并且是非標準協議的認證服務，此時你可以考慮使用 forward-auth 插件。使用該插件可以將用戶的請求通過 HTTP 形式轉發至認證服務中，并在認證服務響應非正常狀態（錯誤碼非 20x）時，返回自定義報錯或者將用戶重定向至認證頁面。
借助 forward-auth 插件的能力，可以非常巧妙地將認證與授權邏輯轉移到專門的、非標準協議的外部服務中。
用戶認證只是 APISIX 保障 API 安全的第一步，將認證能力與其他安全類型插件的有機結合將會進一步放大網關的安全能力。
在一個復雜的后端系統中，可能會存在部分 API 的安全限制是高于其他 API 的，這種限制不僅需要攔截匿名用戶，而且需要對認證用戶進行限制，例如：只允許白名單用戶訪問用戶管理 API。
此時我們可以使用 APISIX 提供的?consumer-restriction?插件去實現一個訪問控制機制。
curl http://127.0.0.1:9180/apisix/admin/routes -H 'X-API-KEY: your-API-key' -X POST -i -d '
{
"uri": "/api/v1/users/admin",
"plugins": {
"key-auth": {},
"consumer-restriction": {
"whitelist": [
"Rose",
"Peter
]
}
},
"upstream": {
...
},
}上述配置中，通過 key-auth 和 consumer-restriction 兩個插件限制了：/api/v1/users/admin 路由需要通過 key auth 認證，并且僅 Rose 和 Peter 可以訪問。
前面我們介紹了可以通過在 Consumer 中配置認證插件將用戶憑證與消費者進行關聯，事實 APISIX Consumer 對象不僅僅可以掛載認證類型的插件，而是可以像路由和 Service 一樣，掛載任意插件。
以限流場景舉例，在實際應用中，限流策略往往不是一成不變而是”千人千面”，不同服務等級的調用方擁有不同的 API 限流策略是非常常見的需求，這樣的需求是無法通過在路由上掛載限流插件進行解決的。為此，我們可以在消費者上掛載限流插件，并且為每一個消費者指定不同的限流策略。
curl http://127.0.0.1:9180/apisix/admin/consumers -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
"username": "jack",
"plugins": {
"key-auth": {
"key": "jack"
},
"limit-count": {
"count": 200,
"time_window": 60,
"rejected_code": 503,
"key": "$consumer_name",
}
}
curl http://127.0.0.1:9180/apisix/admin/consumers -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
"username": "rose",
"plugins": {
"key-auth": {
"key": "rose"
},
"limit-count": {
"count": 1000,
"time_window": 60,
"rejected_code": 503,
"key": "$consumer_name",
}
}通過上方的配置，我們為 jack 和 rose 分別指定了不同的限流策略。Rose 在 60 秒內擁有更多的請求次數配額 1000，而 Jack 只有 200 配額。
認證鑒權作為 API 網關不可或缺的能力，已然成為用戶在選型 API 網關時考量的重要因素之一。
本文中介紹的開源網關 Apache APISIX，覆蓋了所有主流的認證方式，可以滿足企業用戶對于認證鑒權的需求。同時 APISIX 還擁有其他以下優勢：
這些優勢都可以幫助企業更輕松的落地網關層面的認證鑒權，加強 API 安全。
