Http中的Auth：
分2种：
- authorization：针对权限。e.g:后端非管理员接口的调用403(权限不足)
- authentication:针对用户名密码登录的身份认证。错误码是401.(没有登录)
HTTP中如何认证身份：
http是无状态的，会导致一个问题：
第一次请求中进行了登录，第2次请求执行一些操作的时候，在这次请求是不知道上一次请求是已经登录的，所以第2次请求也是无状态的。服务端如何去确保第2次请求是刚才登录过的客户端再次发起的请求？
Auth的认证方式：
1.Session（旧的方式）
session是存储在server端的key-value的存储在内存中的结构。
http请求第一次登录，登录完成后服务端会记一个sessionId和值。值包含元数据信息，并把sessionId下发到客户端，等下一次请求的时候会将sessionId带到Cookie中交给服务端，服务端会根据这个Cookie中的sessionId去找，找到了匹配的话就对这个用户的身份认证完毕了。然后可能会返回一些信息等。。
缺点：session默认存储在当前服务器，如果进行了nginx分布式处理，反向代理给3台机器，第一个请求给其中1台机器，第2个请求可能是登录完成后获取信息，此时可能因为负载均衡的原因打到其他2台机器中的一台上，此时的机器上没有用对应的session，导致认为没有登录的。解决方案：nginx配置基于客户端ip hash的负载均衡的方案或将session存到共享的sever上。
还有种自己想的解决无状态的问题：每次请求都带上用户名和密码进行登录校验，成功校验后再进行其他操作。【这是一种很正规的方式，看似很蠢】
2. Authorization:是一个Http的Header，有格式的要求，形式为：TYPE XXXX
其2种形式：
- Basic：将用户名和密码直接放到内容部分。每次i请求中都会带上Authorization这个Header。即每次都携带用户名密码上传。当然用户名密码进行了简单的处理：Base64(username,password).服务端，对Header进行解析发现是Basic类型，把内容拿出来进行Base64.decode的解码。（不用担心截获，请求一般都在https上，抓包都抓不下来。）【简单粗暴但有效】（缺点：每次访问都需要拿出username password和数据库比对认证，耗时间）
- Bearer：其后接token。token是一个令牌。token的生成方式有很多。比较有代表性的是JWT(json web token)
比如用户第一次登录把用户名密码提交给server，服务端验证成功后使用一个对称加密算法AES(userid,key)含有userid等拼起一个字符串，然后再使用security key，这个key是服务端自己知道的很长的一个文本。将加密后的密文发给客户端。客户端下一次请求中将token携带到Authorization的header中传到服务端，服务端通过AES解密算法和token解密出元数据信息，进而将用户的身份进行了认证。
代码实操：
这里以node的express框架演示并安装一个basic-auth的包：
这个乱码是使用base64：
针对barer形式，典型的有JWT:
其中header部分是标明了元数据信息。
header和playload只是进行了base64的编码，并没有进行加密。
最后一部分是签名部分，签名部分不是base64了。
HS256和AES不一样，它是一种Hash算法、单向的。
认证原理：
用户登录成功--> 生成jwt
用户再次上传jwt-->剥离出3部分，并再次将前2部分和secret运行hsah看结果是否与上传的结果一样。
当用户登录成功后可以把用户的元信息记录到playload中。
实操：使用jwt提供的库完成barer形式的认证
进入github查看使用方式。
需要先安装模块：
npm install jsonwebtoken
jsonwebtoken有提供过期时间。
拿到这个token后只能说是登录成功了，我们还需要进行其他的操作。
复制token,
