kong笔记——kong的权限认证插件选择参考

kong笔记——目录导航

kong自身共提供了这么几个权限认证插件：

1. basic auth;
2. key auth;
3. hmac auth;
4. jwt auth;
5. oauth2 auth

接下来来逐个介绍其特点以及使用场景，性能表现。

Basic auth

基本介绍

基本认证是一种用来允许Web浏览器或其他客户端程序在请求时提供用户名和口令形式的身份凭证的一种登录验证方式，通常用户名和密码会通过HTTP头传递。

在发送之前是以用户名追加一个冒号然后串接上密码，并将得出的结果字符串再用Base64算法编码。

eg:

提供的用户名是:admin

口令是:123456

拼接后的结果是：admin:123456，然后再将其用Base64编码的字符串为：YWRtaW46MTIzNDU2

最终将Base64编码的字符串追到到header中发送出去，由接收者解码得到一个由冒号分隔的用户名和口令的字符串

服务端：

curl -i -X GET \ --url http://localhost:8000/request/ \

–header “Host: example.com” \

–header ‘Authorization: Basic YWRtaW46MTIzNDU2’

浏览器：

优缺点

优点

简单，被广泛支持

缺点

不安全

1. 用户HTTP是在网络上裸奔的，所以这个基本认证的用户名和密码也是可以被人看到的，虽然它使用了Base64来编码，但这个编码很容易就可以解码出来；
2. 即使这个认证内容不能被解码为原始的用户名和密码也是不安全的，恶意用户可以再获取了认证内容后使用其不断的享服务器发起请求，这就是所谓的重放攻击；
3. 中间人可以修改报文然后请求服务器。

使用场景

1. 内部网络，或者对安全要求不是很高的网络；

2. 结合HTTPS一起使用，https保证网络的安全性，然后基本认证来做客户端身份识别；

   在结合了HTTPS后，Basic Authentication 可以说还是有一定的市场的，但是其重要性正在降低。因为合适的使用场景太少。我们可以想象一下：如果服务器是允许匿名用户访问的，那你就没有必要认证。如果服务器是不允许匿名访问的，那么需要用户注册，就会使用用户凭证认证，也不需要基本认证。只有那种只需要一个特定密码就可以访问的场景，例如加了提取码的网盘资源。

性能压测

前提条件：不走kong代理，双pod节点（每个节点参数是2核2G），200并发，响应超时时间3s，配置自定义插件生成广告自定义日志

以上条件目前压测的qps为13,579.93；

1. 添加完 basic auth 权限之后，qps为：11999.25 性能下降约为：11%

2. 在以上基础上添加授权插件后，qps为11,258.77，性能约下降约17%；

key auth

基本介绍

同Basic auth；区别是用户名密码的形式变成了密钥形式，每次验证密钥，通过就可以访问了；

验证有两种方式：

服务端：

$ curl -i -X GET \
  --url http://localhost:8000/auth \
  --header "Host: example.com" \
  --header "apikey: toutiao"

浏览器：

优缺点

优点

同Basic auth

缺点

同Basic auth

使用场景

更适用于面向开发人员，拿到密匙后可以调用第三方的api了

性能压测

前提条件：不走kong代理，双pod节点（每个节点参数是2核2G），200并发，响应超时时间3s，配置自定义插件生成广告自定义日志

以上条件目前压测的qps为13,579.93；

1. 添加完 key auth 权限之后，qps为：11998.5 性能下降约为：11%

2. 在以上基础上添加授权插件后，qps为11,842.95，性能约下降约12%；

hmac

基本介绍

HMAC技术，这个东西来自于MAC – Message Authentication Code，是一种用于给消息签名的技术，也就是说，我们怕消息在传递的过程中被人修改，所以，我们需要用对消息进行一个MAC算法，得到一个摘要字串，然后，接收方得到消息后，进行同样的计算，然后比较这个MAC字符串，如果一致，则表明没有被修改过（整个过程参看下图）。而HMAC – Hash-based Authenticsation Code，指的是利用Hash技术完成这一工作，比如：SHA-256算法。

1. 客户端需要在认证服务器中预先设置 access key（AK 或叫 app ID） 和 secure key（SK）
2. 在调用 API 时，客户端需要对参数和 access key 进行自然排序后并使用 secure key 进行签名生成一个额外的参数 digest
3. 服务器根据预先设置的 secure key 进行同样的摘要计算，并要求结果完全一致
4. 注意 secure key 不能在网络中传输，以及在不受信任的位置存放（浏览器等）

优缺点

优点

安全，可以防止重放攻击

缺点

没有统一的标准，各家实现不一致

使用场景

微信的签名算法(这里，我们需要说明一下，微信的API没有遵循HTTP协议的标准，把认证信息放在HTTP 头的 Authorization 里，而是放在body里)

api间互相调用的认证

性能压测

前提条件：不走kong代理，双pod节点（每个节点参数是2核2G），200并发，响应超时时间3s，配置自定义插件生成广告自定义日志

以上条件目前压测的qps为13,579.93；

1. 添加完 hmac auth 权限之后，qps为：10,758.67 性能下降约为：20%

2. 在以上基础上添加授权插件后，qps为： 10,097.97，性能约下降约：24%；

Jwt

基本介绍

JWT是一个比较标准的认证解决方案，这个技术在Java圈里应该用的是非常普遍的。JWT签名也是一种MAC（Message Authentication Code）的方法。JWT的签名流程一般是下面这个样子：

1. 用户使用用户名和口令到认证服务器上请求认证。
2. 认证服务器验证用户名和口令后，以服务器端生成JWT Token，这个token的生成过程如下：
   • 认证服务器还会生成一个 Secret Key（密钥）
   • 对JWT Header和 JWT Payload分别求Base64。在Payload可能包括了用户的抽象ID和的过期时间。
   • 用密钥对JWT签名 HMAC-SHA256(SecertKey, Base64UrlEncode(JWT-Header)+’.’+Base64UrlEncode(JWT-Payload));
3. 然后把 base64(header).base64(payload).signature 作为 JWT token返回客户端。
4. 客户端使用JWT Token向应用服务器发送相关的请求。这个JWT Token就像一个临时用户权证一样。

当应用服务器收到请求后：

1. 应用服务会检查 JWT Token，确认签名是正确的。
2. 然而，因为只有认证服务器有这个用户的Secret Key（密钥），所以，应用服务器得把JWT Token传给认证服务器。
3. 认证服务器通过JWT Payload 解出用户的抽象ID，然后通过抽象ID查到登录时生成的Secret Key，然后再来检查一下签名。
4. 认证服务器检查通过后，应用服务就可以认为这是合法请求了。

优缺点

优点

1.体积小，因而传输速度快
2.传输方式多样，可以通过URL/POST参数/HTTP头部等方式传输
3.严格的结构化。它自身（在 payload 中）就包含了所有与用户相关的验证消息，如用户可访问路由、访问有效期等信息，服务器无需再去连接数据库验证信息的有效性，并且 payload 支持为你的应用而定制化。
4.支持跨域验证，可以应用于单点登录。

缺点

1.Token有长度限制
2.Token不能撤销

使用场景

JWT的主要优势在于使用无状态、可扩展的方式处理应用中的用户会话。服务端可以通过内嵌的声明信息，很容易地获取用户的会话信息，而不需要去访问用户或会话的数据库。在一个分布式的面向服务的框架中，这一点非常有用。

性能压测

前提条件：不走kong代理，双pod节点（每个节点参数是2核2G），200并发，响应超时时间3s，配置自定义插件生成广告自定义日志

以上条件目前压测的qps为13,579.93；

1. 添加完 jwt 权限之后，qps为：10,495.57 性能下降约为：22%

2. 在以上基础上添加授权插件后，qps为： 10,267.17，性能约下降约24%；

Oauth 2.0

基本介绍

上面的这些API认证都是要向Client发一个密钥（或是用密码）然后用HASH或是RSA来签HTTP的请求，这其中有个主要的原因是，以前的HTTP是明文传输，所以，在传输过程中很容易被篡改，于是才搞出来一套的安全签名机制，这些认证的玩法是可以在HTTP明文协议下玩的。

这种使用签名方式大家可以看到是比较复杂的，所以，对于开发者来说，也是很不友好的，在组织签名的那些HTTP报文的时候，各种，URLEncode和Base64，还要对Query的参数进行排序，然后有的方法还要层层签名，非常容易出错，另外，这种认证的安全粒度比较粗，授权也比较单一，对于有终端用户参与的移动端来说也有点不够。所以，在2012年的时候，OAuth 2.0 的 RFC 6749 正式放出。

OAuth 2.0依赖于TLS/SSL的链路加密技术（HTTPS），完全放弃了签名的方式，认证服务器再也不返回什么 secret 的密钥了，所以，OAuth 2.0是完全不同于1.0 的，也是不兼容的

理解OAuth 2.0 - 阮一峰的网络日志

OAuth 2.0 的四种方式 - 阮一峰的网络日志

优缺点

优点

1. 实施代码量小;
2. 维护工作减少;
3. 可以比较方便的接入第三方登录;
4. Facebook 的 Graph API 只支持OAuth 2.0协议，Google 和 Microsoft Azure 也支持Auth 2.0，国内的微信和支付宝，微博等也支持使用OAuth 2.0;
5. 更细粒度的权限验证。

缺点

1. 只能在https下使用；
2. OAuth2是一个安全框架，描述了在各种不同场景下，多个应用之间的授权问题。有海量的资料需要学习，要完全理解需要花费大量时间；
3. OAuth2不是一个严格的标准协议，因此在实施过程中更容易出错。

使用场景

第三方授权登录

性能压测

目前由于没有https环境，没法测试

参考文献

常用的认证&授权方法以及在kong上的实践

JWT和HMAC(AK/SK)认证方式使用场景