在之前的的文章中我们提到我们自己开发了一个Apisix的认证插件来实现认证，但是实际过程当中，我们同样也希望支持使用Keycloak，Authing，okta这类统一身份认证。本文主要是说明我们如何使用Authing这个身份认证供应商来实现登录认证的。
交互流程
如图所示，途中包括了网关认证过程中涉及到的所有组件。
- 客户在办公网/公有云/数据中心当中运行一个连接器，连接器本身作为网关的客户端，不监听任何端口。
- Apisix网关是我们基于Apisix构建的一个七层网关，作为连接器的服务端，接收连接器的连接请求，同时也作为用户访问的流量入口，负责接收所有外部访问的流量，同时也运行着一个对接控制面的模块，专门与数据面进行rpc/http交互
- 身份认证组件，也就是我们的auth组件，统一了身份认证功能，屏蔽其他认证组件像Authing，Keycloak的细节。无论使用何种认证方式，对于Apisix网关而言都是一致的，也就是很经典的没有什么是加一层中间件解决不了的思想
具体交互流程如下：
- 用户通过浏览器访问Apisix网关
- Apisix发现用户没有登录，会返回一个重定向请求，重定向到身份认证组件的一个接口
- 身份认证组件获取这个应用的信息，主要是使用了哪种身份认证的方式
- 如果使用的是我们自建的身份认证，那么会重定向到自建身份认证的登录地址
- 如果使用的是第三方的身份认证，那么会重定向到第三方身份认证的登录地址
- 通过这种方式，我们可以对apisix提供一个统一的登录地址，Apisix并不需要关注这个应用使用的是哪种登录方式
- 用户的浏览器自动跳转到重定向地址，然后进行登录
- 如果是比扬云自建的身份认证，登录之后会返回一次性code和state给浏览器，浏览器携带code和state跳转到用户希望访问的资源链接，Apisix收到请求之后，首先会根据code和state去查询token信息，并设置cookie，保证下次能查询到token信息
- 如果是第三方身份认证信息，由于网站不是我们自己开发的，我们无法控制浏览器行为，因此在登录成功之后，会跳转到我们认证服务的一个接口，在接口处理当中继续走类似比扬云身份认证的登录逻辑，后续跟正常使用比扬云身份认证的流程是一致的
通过这种方式，我们就能够实现扩展性比较好的身份认证功能，如果后续需要新增其他身份认证，只需要在身份认证服务当中进行对接，不需要Apisix网关的任何修改，而这也符合我们对网关的要求——网关稳定了就一直保持着就行，不需要频繁更改。
详细操作
第一步：创建连接器
登录我们的控制台选择零信任网关下拉，点击连接器管理，点击新增按钮，填入名称和配置即可
连接器创建成功之后会生成一个唯一的授权码，这个授权码在第二步当中会用到。
第二步：运行连接器
在连接器下载菜单栏下选择对应平台的连接器程序，本次我使用的是一个linux amd64平台的连接器，然后执行
./connector_linux_amd64 -auth=第一步生成的授权码
运行成功之后刷新连接器信息就能看到连接器是否在线
第三步：新增Authing身份认证
在身份认证供应商菜单下，点击新增按钮，在弹出来的页面当中输入名称，厂商选择Authing，然后输入您在Authing平台当中创建的应用的APPID，AppSecret和认证地址，这里的信息和Authing控制台里面显示的都是一致的，只需要找到然后复制粘贴过来即可。
第四步：创建应用
在应用管理菜单栏下，点击新增，在完善弹出的页面。其中连接器选择下拉选择第一步当中创建的连接器，认证方式下拉选择Authing，其他的根据实际情况决定，比如我的应用IP是192.168.1.10，端口是80，协议是http
第五步：访问测试
配置成功之后就可以进行测试，通过在浏览器打开应用列表里面的接入地址。首次打开会跳转到Authing的登录页面，登录成功之后会跳转到你的内网应用的页面。
总结
在之前的文章中我们也提到了做身份认证并不是我们当前擅长的事，我们更愿意将身份认证的功能留给第三方，比如Authing，Keycloak，Authing的集成是一个新的探索，我们也在积极寻找合作机会，如果您对我们的产品感兴趣的话，可以登录我们的控制台进行免费使用。
