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

	基本介绍	优	缺	使用场景
	基本介绍	优	缺	使用场景
basic auth	HTTP Basic Auth 在HTTP中，基本认证是一种用来允许Web浏览器或其他客户端程序在请求时提供用户名和口令形式的身份凭证的一种登录验证方式，通常用户名和明码会通过HTTP头传递。在发送之前是以用户名追加一个冒号然后串接上口令，并将得出的结果字符串再用Base64算法编码。例如，提供的用户名是Aladdin、口令是open sesame，则拼接后的结果就是Aladdin:open sesame，然后再将其用Base64编码，得到QWxhZGRpbjpvcGVuIHNlc2FtZQ==。最终将Base64编码的字符串发送出去，由接收者解码得到一个由冒号分隔的用户名和口令的字符串。 参考： https://blog.pytool.com/devops/oauth2/jwt/	简单，被广泛支持	不安全 安全分几个层面：内容的篡改及嗅探。这是HTTP协议本身存在的问题，所以很难根除，以后的网络世界会慢慢全部转为使用更加安全的HTTPS的。 1 用户HTTP是在网络上裸奔的，所以这个基本认证的用户名和密码也是可以被人看到的，虽然它使用了Base64来编码，但这个编码很容易就可以解码出来。 2 即使这个认证内容不能被解码为原始的用户名和密码也是不安全的，恶意用户可以再获取了认证内容后使用其不断的享服务器发起请求，这就是所谓的重放攻击。 3 像中间人攻击就更不能防止了，中间人可以修改报文然后请求服务器。	内部网络，或者对安全要求不是很高的网络。现如今HTTP基本认证都是会结合HTTPS一起使用的，https保证网络的安全性，然后基本认证来做客户端身份识别。 在结合了HTTPS后，Basic Authentication 可以说还是有一定的市场的，但是其重要性正在降低。因为合适的使用场景太少。我们可以想象一下：如果服务器是允许匿名用户访问的，那你就没有必要认证。如果服务器是不允许匿名访问的，那么需要用户注册，就会使用用户凭证认证，也不需要基本认证。只有那种只需要一个特定密码就可以访问的场景，例如加了提取码的网盘资源。
key auth	同上，只不过不用每次验证密码，第一次登录成功后拿到key和密匙，后续只需要每次带着，验证密匙通过，就可以访问了	同上	同上	感觉更适用于面向开发人员，拿到密匙后可以调用第三方的api了
hmac	HMAC技术，这个东西来自于MAC – Message Authentication Code，是一种用于给消息签名的技术，也就是说，我们怕消息在传递的过程中被人修改，所以，我们需要用对消息进行一个MAC算法，得到一个摘要字串，然后，接收方得到消息后，进行同样的计算，然后比较这个MAC字符串，如果一致，则表明没有被修改过（整个过程参看下图）。而HMAC – Hash-based Authenticsation Code，指的是利用Hash技术完成这一工作，比如：SHA-256算法。   客户端需要在认证服务器中预先设置 access key（AK 或叫 app ID） 和 secure key（SK） 在调用 API 时，客户端需要对参数和 access key 进行自然排序后并使用 secure key 进行签名生成一个额外的参数 digest 服务器根据预先设置的 secure key 进行同样的摘要计算，并要求结果完全一致 注意 secure key 不能在网络中传输，以及在不受信任的位置存放（浏览器等） 参考：https://zhuanlan.zhihu.com/p/60522006 https://coolshell.cn/articles/19395.html	安全，可以防止重放攻击	没有统一的标准，各家实现不一致	Acquia 的 HMAC，微信的签名算法
jwt	JWT是一个比较标准的认证解决方案，这个技术在Java圈里应该用的是非常普遍的。JWT签名也是一种MAC（Message Authentication Code）的方法。JWT的签名流程一般是下面这个样子： 用户使用用户名和口令到认证服务器上请求认证。 认证服务器验证用户名和口令后，以服务器端生成JWT Token，这个token的生成过程如下： 认证服务器还会生成一个 Secret Key（密钥） 对JWT Header和 JWT Payload分别求Base64。在Payload可能包括了用户的抽象ID和的过期时间。 用密钥对JWT签名 HMAC-SHA256(SecertKey, Base64UrlEncode(JWT-Header)+'.'+Base64UrlEncode(JWT-Payload)); 然后把 base64(header).base64(payload).signature 作为 JWT token返回客户端。 客户端使用JWT Token向应用服务器发送相关的请求。这个JWT Token就像一个临时用户权证一样。 当应用服务器收到请求后： 应用服务会检查 JWT  Token，确认签名是正确的。 然而，因为只有认证服务器有这个用户的Secret Key（密钥），所以，应用服务器得把JWT Token传给认证服务器。 认证服务器通过JWT Payload 解出用户的抽象ID，然后通过抽象ID查到登录时生成的Secret Key，然后再来检查一下签名。 认证服务器检查通过后，应用服务就可以认为这是合法请求了。 参考： https://coolshell.cn/articles/19395.html https://blog.pytool.com/devops/oauth2/jwt/ 《JSW：The Complete Guide to JSON Web Tokens》	1.体积小，因而传输速度快 2.传输方式多样，可以通过URL/POST参数/HTTP头部等方式传输 3.严格的结构化。它自身（在 payload 中）就包含了所有与用户相关的验证消息，如用户可访问路由、访问有效期等信息，服务器无需再去连接数据库验证信息的有效性，并且 payload 支持为你的应用而定制化。 4.支持跨域验证，可以应用于单点登录。