关于apisix:认证鉴权对于-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 这个消费者进行关联。能够看到，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 平安。