認證鑒權對于 API 網關的重要性

認證鑒權作為 API 網關不可或缺的能力，已然成為用戶在選型 API 網關時考量的重要因素之一。

作者錢勇，API7.ai 開發工程師，Apache APISIX Committer

在當下云原生越發成熟的環境下，API 網關最核心的功能可以概括為：連接 API 消費者和 API 提供者。

實際場景中，除去少部分允許匿名訪問的 API 外，提供者往往都會對消費者有所限制，比如只有符合條件的消費者才可以對 API 進行訪問。其次，提供者對于不同的消費者的訪問策略可能并不相同，例如 A、B 消費者都可以訪問 /send_mail API，但每分鐘的調用頻次需要區分計算。

從以上兩點可以看出在 API 網關層面鑒別和驗證 API 消費者的身份至關重要。本文將介紹云原生開源 API 網關 Apache APISIX 如何實現對于消費者的認證，以及目前被企業廣泛采用的認證方式。進一步介紹 APISIX 的用戶認證體系是如何與其他安全特性聯動使用，從而進一步提升 API 網關的安全防護能力。

Apache APISIX 的認證鑒權

Apache APISIX 是一個動態、實時、高性能的 API 網關，提供負載均衡、動態上游、灰度發布、精細化路由、限流限速、服務降級、服務熔斷、身份認證、可觀測性等數百項功能。在認證鑒權方面，APISIX 也是提供了非常多且方便的途徑。

傳統的 HTTP 代理往往只能基于請求域名、客戶端 IP 等粗粒度手段對請求方進行識別，這對于一款 API 網關來說是遠遠不夠的，我們需要有更豐富的認證方式來解決越來越復雜的業務需求。而 APISIX 區分于傳統代理的一大優勢就是靈活的插件擴展能力，這其中就包括一套用于用戶認證的插件集合，這些插件根據實現方式的不同可以分為兩大類。

第一種是對接外部認證服務，委托其進行認證。

第二種則是在網關內部認證，配合 APISIX 設計的 Consumer 對象進行認證。

下面將會依次介紹這兩種認證方式。

對接外部認證服務

在企業采用 API 網關之前，系統中往往已經部署了獨立的認證服務，此時我們要如何將 APISIX 與已有的認證服務進行對接呢？APISIX 提供了這樣一系列插件，它們的工作原理就是通過對接各種外部的認證服務，委托它們完成認證。

例如，我們可以使用 openid-connect 插件對接任意支持 OIDC 協議的認證服務，下面是一段對接到 Keycloak 服務的樣例配置：

curl http://127.0.0.1:9180/apisix/admin/routes -H "X-Api-Key: your-API-key" -XPOST -d '
{
    "uri":"/*",
    "plugins":{
        "openid-connect":{
            "client_id":"apisix", // keycloak 創建 client 時生成
            "client_secret":"d5c42c50-3e71-4bbe-aa9e-31083ab29da4",
            "discovery":"http://keycloak:8080/auth/realms/apisix_test_realm/.well-known/openid-configuration", // keycloak OpenID Endpoint
            "scope":"openid profile",
            "bearer_only":false,
            "realm":"apisix_test_realm",
            "introspection_endpoint_auth_method":"client_secret_post",
            "redirect_uri":"http://127.0.0.1:9080/"
        }
    },
    "upstream":{
        ...
    }
}'

網關內部認證

Consumer

當來自多渠道的請求到達 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 這個消費者進行關聯?？梢钥吹?#xff0c;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 的插件機制極大地降低了實現各種認證方式的開發成本，以下是部分 APISIX 已經支持的主流認證方式。

Key Auth

Key Auth 是目前 APISIX 所支持的認證方式中，使用起來最簡單的。但 key-auth 插件在實際環境中有著非常豐富的應用場景，例如：收費軟件中的 License、開放 API 平臺中的用于標識開發者的 token 等等，都可以非常輕松地使用 key-auth 來實現。并且基于 APISIX 全動態的配置下發能力，Key 可以被迅速創建、吊銷，而且實時生效。

Basic Auth

Basic Auth 是基于用戶名、密碼進行認證的方式，常用于網頁登錄場景，例如：網站的管理后臺需要管理員登錄后才可以使用，那么我們可以使用 Basic Auth 方式進行認證。

LDAP

LDAP（Lightweight Directory Access Protocol）是一種基于X.500 標準的輕量級文件訪問協議，通過IP 協議提供訪問控制和維護分布式信息的目錄信息，借助于 LDAP ，運維人員可以細粒度地控制用戶對資源的訪問權限。通過 APISIX 的 ldap-auth 插件，可以輕松對接實現了 LDAP 協議的平臺，例如微軟的 Active Direcory，或者 Linux 平臺的 OpenLDAP Server，從而能夠精細化地控制 Consumer 對具體路由的訪問權限。

OIDC

OpenID 是一個去中心化的網上身份認證系統。對于支持 OpenID 的網站，用戶不需要記住像用戶名和密碼這樣的傳統驗證標記。取而代之的是，他們只需要預先在一個作為 OpenID 身份提供者（identity provider, IdP）的網站上注冊賬號，而后就可以用這個賬號登錄所有對接了該提供者的應用，例如：可以通過知名的 Google 或者 Facebook 服務的賬號來認證我們自身系統的用戶。

針對 OIDC，APISIX 提供了 openid-connect 插件，可以用于對接支持了 OIDC 協議的認證服務。

Forward Auth

當 APISIX 的標準認證插件無法滿足你當前需求時，或者當前系統中已經部署了專門的并且是非標準協議的認證服務，此時你可以考慮使用 forward-auth 插件。使用該插件可以將用戶的請求通過 HTTP 形式轉發至認證服務中，并在認證服務響應非正常狀態（錯誤碼非 20x）時，返回自定義報錯或者將用戶重定向至認證頁面。

借助 forward-auth 插件的能力，可以非常巧妙地將認證與授權邏輯轉移到專門的、非標準協議的外部服務中。

“認證+任意功能”，APISIX 助力 API 安全

用戶認證只是 APISIX 保障 API 安全的第一步，將認證能力與其他安全類型插件的有機結合將會進一步放大網關的安全能力。

ACL 訪問控制

在一個復雜的后端系統中，可能會存在部分 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 安全。