关于token、签名、加密的一点理解

在之前的工作中，总是接触到这些概念，之前都是零散的理解，在此总结下，以方便以后查阅

一、token 

在网站、app与服务器交互的过程中，很多时候为了：

1、避免用户多次输入密码

2、实现自动登陆

3、避免在终端直接存储用户的密码

4、标示客户端的请求是否合法

5、其他（暂时没想到）

我们需要引入token机制，基于Token的验证流程一般是这样的：

1. 客户端使用用户名跟密码请求登录
2. 服务端收到请求，去验证用户名与密码
3. 验证成功后，服务端会签发一个 Token，这个Token是与用户名一一对应的，token一般可以存储在缓存或数据库中，以方便后面查询出来进行验证。再把这个 Token 发送给客户端
4. 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
6. 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据

Token存在过期时间，在Token生成的时候可以打上一个时间戳，验证token的时候同时验证是否过期，并告知终端。终端接收到token过期的返回后，则要求用户重新输入用户名跟密码，进行登录。

用户的一些操作需要从新请求服务端下发token，如退出、修改密码后重新登录。

二、加密解密

在客户端与服务器进行交互时，必然涉及到交互的报文（或者通俗的讲，请求数据与返回数据），如果不希望报文进行明文传输，则需要进行报文的加密与解密。

所以加密的主要作用就是避免明文传输，就算被截获报文，截获方也不知道报文的具体内容。

我在平时用的比较多的加密算法主要是对称加密中的3DES加密与非对称加密中的RSA。对于这2个加密算法的用法，可自行google。

三、签名

为什么要签名？

1、在客户端与服务器进行交互时，报文虽然加密了，但我们并不能确认这个报文是谁发过来的。例如，与第三方服务器B进行交互时，我方收到了一个已加密的请求，但我方并不能确认是服务器B发送的这个报文，此时我们可以用数字签名的方式来进行验证。作用：认证数据来源 

2、如果我方收到一个B服务器签名的请求，那么B服务器也无法否认这个请求，因为带有它的签名，作用：抗否认性。

3、我方收到一个B服务器签名的请求，但我方并不能确认这个请求是否被篡改过（虽然报文加了密，也可能被篡改），此时即可用签名，验证签名中的报文与传过来的报文是否一致。作用：保证了数据的完整性

平时工作中用的最多的签名算法是：RSA。

遵循规则：公钥加密，私钥解密

总结：在实际开发工作中应该 先通过web filter 解密，解密后进行验证签名(返回数据时，过程反过来，先签名再加密)；然后再springmvc的Interceptor 中进行验证token