前言
上游服务（代理的API或微服务）的流量通常由各种Kong身份验证插件的应用程序和配置控制。 Kong的service概念与上游服务是一对一映射，因此可以通过在service上配置认证插件来控制访问上游服务的权限。
核心概念
- service：上游服务的抽象，与上游服务是一对一映射， 比如后端微服务，API等。
- consumer：消费者的核心原则是您可以将插件附加到他们，从而自定义请求行为，消费者可以代表一个用户，一个应用程序等。
通用认证
最常见的情况是要求进行身份验证，并且不允许访问任何未经身份验证的请求。 为此，可以使用任何身份验证插件。 这些插件的通用方案/流程如下：
-
将认证插件应用到
service，或全局应用。 -
创建一个
consumer。 -
为
consumer配置凭据。 -
有任何请求进入，Kong都会检查提供的凭据（取决于身份验证类型），并且如果无法验证将阻止该请求。
匿名访问
Kong可以配置给定服务同时允许身份验证和匿名访问。一种可能的应用场景是，允许低频访问的匿名，而高频访问的必须验证。因此所有的认证插件都有一个config.anonymous的配置。
要实现匿名访问，首先要创建一个不添加任何凭据的consumer，然后添加一个认证插件，设置认证插件的config.anonymous为consumer的id。以Key认证为例，当在service启用key认证时，必须携带配置好的key name参数及consumer配置好的有效凭据，例如：http://localhost/mockauth?apikey=open_sesame，但如果配置了config.anonymous，则可以不携带，直接访问http://localhost/mockauth，匿名访问与Key认证是逻辑或的关系，满足之一即可。
多重认证
要理解多重认证，首先要理解上面的匿名访问逻辑。
Kong支持给定服务的多个身份验证插件，从而允许不同的客户端使用不同的身份认证方式，来访问给定的服务或路由。这些插件在执行验证行为时，可以有AND，OR的关系，也就是说可以自由配置是满足所有验证还是满足其中一个或几个。验证行为的逻辑关键在于config.anonymous的配置。
-
如果未设置
config.anonymous，认证插件将始终执行验证。 -
如果设置了
config.anonymous，将允许匿名访问，认证插件将仅在尚未通过身份验证的情况下执行身份验证。
假设某service同时安装key-auth，basic-auth插件（以下简称A，B），并且都启用的情况下：
- 若 A，B都没有设置
config.anonymous，则逻辑关系为A and B，A和B必须同时认证成功。 - 若A设置
config.anonymous，B没有，则逻辑关系为（A or 匿名）and B，B认证成功或A，B同时认证成功。 - 若A，B都设置了
config.anonymous，则逻辑关系为（A or 匿名）and (B or 匿名)，可以匿名访问。 - 若A，B都设置了
config.anonymous，同时采用request-termination禁止匿名访问，则逻辑关系为A or B ，A或者B认证成功即可。
来源：oschina
链接：https://my.oschina.net/wecanweup/blog/4275006