kong的介绍

kong基于nginx开发的API Gateway(可以认为是一个OpenResty应用程序)，可以方便的横向扩展，底层使用Apache Cassandra或PostgreSQL数据库。开发者可以方便的添加已定义的插件，甚至可以自己开发插件并使用，来达到代理、负载均衡、健康检查、日志、登录等功能。 --https://konghq.com/about-kong/

kong的服务架构

请求流程：

1. 浏览器访问域名，经过DNS解析到kong的地址
2. kong根据域名识别到相应服务。 (除了kong的每个服务需要被分配一个域名，域名都指向kong的ip地址)
3. kong对此服务配备的插件(限流、认证、负载均衡)校验
4. 校验成功，获取服务相应资源

oauth2.0的介绍

OAuth在"客户端"(浏览器)与"服务提供商"(接口服务)之间，设置了一个授权层。"客户端"不能直接登录"服务提供商"，只能登录授权层，以此将用户与客户端区分开来。"客户端"登录授权层以后，"服务提供商"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。

在多种客户端授权模式中，常常使用密码模式(resource owner password credentials)。

• A. 向客户端提供用户名和密码
• B. 客户端将用户名和密码发给认证服务器，向后者请求令牌
• C. 认证服务器确认无误后，向客户端提供访问令牌

kong oauth2插件的使用

kong的核心概念：

• upstream：相当于nginx的upstream
  • target：相当于nginx中upstream的server
• service: 相当于nginx的server，可以指向到一个upstream
  • route: 相当于nginx中service的location
• plugin：插件，可以配置到service或者route甚至所有服务
• consumer：用户
  • certificate：凭证

对于kong的oauth插件来说，consumer相当于oauth中的client。
这里kong是不提供用户校验的，所以我们需要自己开发一个backend来做用户的信息校验。

图例：(线段是对应颜色节点的行为)

• 绿色client application: 客户端，前端项目
• 黄色kong: kong / kong dashboard(kong api的GUI项目)
• 蓝色webapp backend: 待开发的用户验证服务，需要连接用户数据库
• 紫色resource service: 资源服务

前端请求流程(即上图client application的三条线段)：
用户注册也是访问backend服务

• 请求backend的域名，请求内容是username和password，获取到token及refresh token。
• 请求资源服务的域名，请求携带token，并获取到数据资源
• token过期后，刷新token