用户密码和cookie，session、token还有AKSK

背景：认证、授权、鉴权和权限控制：

https://segmentfault.com/a/1190000013258488

认证、授权、鉴权和权限控制 | 滩之南

单点登录的通用架构实现 | 滩之南

https://segmentfault.com/a/1190000013010835

基于JWT的token身份认证方案 - 开拖拉机的蜡笔小新 - 博客园

用户名密码

• 用户输入账号、密码提交给服务端认证

存在一个问题，万一被泄漏了，就只能改密码或者用户名了，而且还必须销户。那么我们很自然得想到我们需要给用户账号密码认证加密或者是设置有效期。用户名密码还好，如果应用间访问间隔一段时间就要换密码是很痛苦的。而加密呢就涉及到了解密，安全的加密算法，解密一般来说会有性能损耗。（cookie和session都是基于用户名密码）

当然这里涉及到cookie和seesion还有单点登录的方案可以看上文链接

计算机的很多问题：加一个中间层就可以解决了，如果不行，那就多加几层

Token认证

我们能不能先用账号密码访问一个中间层然后从中间层取个带有效时间的对象呢，后续有效期内，我就使用这个对象来进行访问应用。这就是token也叫令牌。

但是如果报文在中途被劫持，那么token就泄露了，这时(token有效期内)黑客就可以构造任意的请求了，这时候我们就又想既然能加时间，我们是不是可以加更多的内容进去，比如你能调哪个api？但是如果每个api都这样搞，那么你需要保存多少token呢？换一个思路用加密，每次请求都要解密，性能上的损耗可能是我们无法接受的。

那么其实在微服务架构下，一般会有微服务网关，我们可能把这层鉴权和token生成放在网关吗？

当然可以。于是jwt应运而生：基于JWT的token身份认证方案 - 开拖拉机的蜡笔小新 - 博客园

aksk（Access Key Id / Secret Access Key）

AK/SK使用机制

公有云下绝大多数使用assk机制来进行认证鉴权

云主机接收到用户的请求后，系统将使用AK对应的相同的SK和同样的认证机制生成认证字符串，并与用户请求中包含的认证字符串进行比对。如果认证字符串相同，系统认为用户拥有指定的操作权限，并执行相关操作；如果认证字符串不同，系统将忽略该操作并返回错误码。

1.3 流程

判断用户请求中是否包含Authorization认证字符串。如果包含认证字符串，则执行下一步操作。
基于HTTP请求信息，使用相同的算法，生成Signature字符串。
使用服务器生成的Signature字符串与用户提供的字符串进行比对，如果内容不一致，则认为认证失败，拒绝该请求；如果内容一致，则表示认证成功，系统将按照用户的请求内容进行操作。
原理：
　　客户端：
　　　　1. 构建http请求（包含 access key）；
　　　　2. 使用请求内容和 使用secret access key计算的签名(signature)；
　　　　3. 发送请求到服务端。

服务端：
　　　　1. 根据发送的access key 查找数据库得到对应的secret-key；
　　　　2. 使用同样的算法将请求内容和 secret-key一起计算签名（signature），与客户端步骤2相同；
　　　　3. 对比用户发送的签名和服务端计算的签名，两者相同则认证通过，否则失败。