文章目录
参考文章： 数据的加密与签名
彻底理解cookie，session，token
加密
使用场景
当我们传输数据时，如果数据被截获了，那么其他人就可以看到内容了，这时需要加密算法来对数据进行加密，这样其他人截获也只能看到乱码。
过程：
发送者对明文使用密钥加密然后生成密文，接受者再对密文解密得到明文的过程。 现在使用的所有加密算法都是公开的！但是密钥肯定不公开。
对称加密和非对称加密
- 对称加密：如果发送方和接收方使用解密密钥相同，我们则称该方法为对称加密（DES、AES）。对称加密优点是速度快，比如我们发送大量数据，每条数据都用非对称加密则速度太慢。
- 非对称加密：如果不同则为非对称加密（RSA），非对称加密有私钥和公钥，私钥签名，公钥验签。非对称加密优点是更安全，一般私钥放在服务端，服务端的信息黑客是截获不到的，所以更加安全。
签名
加密是对数据进行机密性保护，签名主要用于身份验证。
使用场景
如果我们直接用一个url请求资源暴露出来，则任何人都可以通过该url对我们的服务器进行访问，这就产生了安全问题。
含义
用来验证客户端是否合法。比如黑客知道加密算法了，伪装客户端发来信息，而我们有签名验证，他是无法通过。因为当消息内容和时间不一样了，签名就会不一样，所以黑客因为不知道客户端和服务端指定的密钥是无法生成签名的，当然如果发送密钥就算黑客拿到密钥，他也不知道生成签名使用的算法。所以无法伪造签名。
当签名验证不通过，服务器就拒绝。
实例
项目每条请求都采用签名，发送方和接收方使用相同的密钥securityKey（对称加密）。
签名的生成方式通过（密钥 + 时间 +消息内容）加自定义算法（比如抽取消息内容中截取一些字符）来生成。
然后服务端会校验客户端传来的签名和自己生成的签名是否一致（因为使用生成算法和参数相同），一致时，则通过验证，不一致则说明是伪造的客户端请求。
Token
因为之前的签名我们实在服务器端和服务器端来发送的，也就是我们接收的是另一个服务器端传来的信息。可以使用签名机制来校验请求的合法性。
下面说token，Token是基于签名的，比如说服务器用HMAC-SHA256 算法，加上一个只有我才知道的密钥， 对用户名userId做一个签名。然后把这些放到token里，返回给客户端。客户端下次访问服务器的时候带着这个token，我就知道这是合法的。
Token是在客户端频繁向服务端请求数据，服务端频繁的去数据库查询用户名和密码并进行对比，判断用户名和密码正确与否，并作出相应提示，在这样的背景下，Token便应运而生。Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。也就是说作为token
- 客户端使用用户名跟密码请求登录
- 服务端收到请求，去验证用户名与密码
- 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
- 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 其他地方
- 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
- 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据
目的：这样在每次客户端发送请求的时候，服务器就只需要验证token就可以了，不需要再在数据库查询用户名密码，减轻服务器压力。
签名只能保证自解释的token不被篡改，不防盗用。
token和session其实都是一回事，就是谁有这个字串，谁就能有权限来获取数据。
正常情况下，一个短有效期的token已经足够应付大部分场景了。
cookie和session
session 也是类似的道理，服务器要知道当前发请求给自己的是谁。为了做这种区分，服务器就要给每个客户端分配不同的“身份标识”，然后客户端每次向服务器发请求的时候，都带上这个“身份标识”，服务器就知道这个请求来自于谁了。至于客户端怎么保存这个“身份标识”，可以有很多种方式，对于浏览器客户端，大家都默认采用 cookie 的方式。
这样大家很嗨皮了，可是服务器就不嗨皮了，每个人只需要保存自己的session id，而服务器要保存所有人的session id ！ 如果访问服务器多了， 就得由成千上万，甚至几十万个。这对服务器说是一个巨大的开销。
而为了解决我们使用token， 服务器就不保存session id 了， 我只是生成token , 然后验证token ， 用CPU计算时间获取了我的session 存储空间 ！
现在移动端大多使用token，而网站客户端多使用cookie。
