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

原文标题:关于token、签名、加密的一点理解

原文地址 blog.csdn.net