Token 原理解读

上一篇文章我们了解了一下 cookie 与 session 的产生、作用与原理。尽管二者在历史中已经服役过很长一段时间，但不论什么技术，都会有后来的优秀者取而代之。

前面说到，cookie 因为是保存在客户端，所以有安全隐患，因而诞生了 session，session 保存在服务器端，相对安全很多。但 session 每次都要为用户开辟一个空间用于其身份校验，且每次浏览器的请求过来服务器都要进行校验请求，十分耗费服务器的空间与性能。

于是，另一种身份校验工具诞生了，这就是 token。

本质上还是用户身份验证的工具。但与 cookie、session 明文似的形式不同，token 是经过一系列加密手段加密过的，最后表现为一串“无意义”的字符串。但里面包含了许多信息，可能包括用户登录的终端的地址、用户身份 ID、时间戳以及一个签名。所谓签名就是信息发送者给这段信息进行签名，让信息接收方知道请求 token 是属于谁。可以理解为在你的身份z上签名字，证件加笔迹双重认证。

为了避免上述 CSRF 攻击，浏览器对网页资源的访问提出了限制，URL 请求必须是与页面一样来自同一 协议 、 域名 、 端口 才给予访问权限。这样三者相同的站点被认为是有相同的“源”，是一个独立的“域”。即使 “localhost” 与 “ip” 都指向了本机，但也会被认为是非同源。浏览器在某个“域”下不会执行其他“域”的脚本。因而这也产生了前端领域里一个重要的话题：跨域。

session 的产生来自于用户登录后服务器生成的一个 session 对象，保存在服务器端，这个 session 只适用于该“域”。但实际情况是，一个网站的请求大多数情况下都会跨域，每台服务器的端口不同，甚至是域名就不同，每当跨域时就会形成新的会话，生成新的 session，这是非常影响用户体验的，所以也会有许多保存、共享或中央存储 session 的方案。

但上述两种限制在 token 这里就不再是问题。

与 cookie 类似。

首先，用户输入账号密码，发起登录请求，服务器校验账号密码合法性，成功则返回 token 给客户端。

客户端收到响应后拿到 token，将其通过 localStorage 等本地存储方式进行保存。

当浏览器再次请求时，需要在请求头中添加 token，这样服务器在接收到请求后便可以识别该请求的身份是否合法，合法则返回响应数据。

在实际应用中，配合 axios 的请求拦截器使用起来会很方便：

这样，就不用每次请求都手动添加 token，axios 会自动帮助我们完成添加，十分方便。

其实前端程序员对 token 的涉及没有多深，只需要在需要授权的请求中携带 token 即可。token 的生成、加密等都是后端去处理。所以，这里也就不在赘述 token 的加密原理，以笔者的能力也很难去讲述清楚。

token 运用也不是上文中描述的那么简单，涉及到一些过期处理、refresh 等 *** 作。这些日后有机会再详谈。

手动生成token有以下弊端：

1 安全性较低。手动生成的token可能比较容易被破解，因为token的算法可能不够复杂，可能会有漏洞存在。

2 可能会有重复的token。如果token的算法不够复杂，那么可能会出现重复的token，这样一来，攻击者就可以用这个token来模拟用户的行为。

3 可能会出现失效的token。如果token的算法不够复杂，那么可能会出现失效的token，这样一来，用户就无法使用他们的token来访问应用程序。

JWT（json web token）是为了在网络应用环境之间传递声明而执行的一种基于JSON的开放标准。

JWT的声明一般被用来在 身份提供者 和 服务提供者 间传递被认证的用户身份信息，以便从资源服务器获取资源。比如用于登录。

shiro（9）-有状态身份认证和无状态身份认证的区别

JWT由三部分组成：头部(header)、载荷(payload)、签名(signature)。头部定义类型和加密方式；载荷部分放的不是很重要的数据；签名使用定义的加密方式加密base64后的header和payload和一段自己加密key。最后的token由base64(header)base64(payload)base64(signature)组成。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9eyJvcmciOiLku4rml6XlpLTmnaEiLCJuYW1lIjoiRnJlZeeggeWGnCIsImV4cCI6MTUxNDM1NjEwMywiaWF0IjoxNTE0MzU2MDQzLCJhZ2UiOiIyOCJ949UF72vSkj-sA4aHHiYN5eoZ9Nb4w5Vb45PsLF7x_NY

JWT头部分是一个描述JWT元数据的JSON对象。

完整的头部就像下面这样的json。

然后将头部进行base64加密，构成第一部分：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

载荷是存放有效信息的地方，这些有效部分包含三个部分。

公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息， 但不建议添加敏感的信息，因为这部分在客户端可解密。

私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。

定义一个payload：

然后将其进行base64加密，得到第二部分

eyJvcmciOiLku4rml6XlpLTmnaEiLCJuYW1lIjoiRnJlZeeggeWGnCIsImV4cCI6MTUxNDM1NjEwMywiaWF0IjoxNTE0MzU2MDQzLCJhZ2UiOiIyOCJ9

jwt的第三部分是一个签证信息，这个签证信息由三部分组成：

这个部分需要base64加密后的header和base64加密后的payload使用 连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，就构成了jwt的第三部分：

49UF72vSkj-sA4aHHiYN5eoZ9Nb4w5Vb45PsLF7x_NY

注：密钥secret是保存在服务端的，服务端会根据这个密钥进行生成token和验证，所以要保护好。

解析结果

重放攻击是攻击者获取客户端发送给服务器端的包，不做修改，原封不动的发送给服务器用来实现某些功能。比如说客户端发送给服务器端一个包的功能是查询某个信息，攻击者拦截到这个包，然后想要查询这个信息的时候，把这个包发送给服务器，服务器就会做相应的 *** 作，返回查询的信息。

身份z办理进度的查询通常需要使用身份z号码和查询时期生成的token。如果在通过身份z办理进度查询网站查询时，出现“token无效”提示，可能是以下原因所致：

1 token过期：当您在查询身份z办理进度时，系统会为您生成一个有效期一定时长的token，如果查询时token已过期，也会显示“token无效”的提示消息。

2 *** 作时间间隔过长：为了保护查询安全，系统规定了查询时间间隔。如果您连续查询时间间隔超过了限制，也会出现“token无效”的提示。

3 查询异常：可能是由于网络连接问题或系统故障等原因导致查询异常，进而出现“token无效”的提示。

如果出现“token无效”的提示，您可以尝试重新访问身份z办理进度查询网站，生成一个新的token，或者稍后再次尝试进行查询。如果长时间无法解决问题，可以咨询相关的客服人员寻求帮助。

值得注意的是，为了保护个人信息安全，查询时请勿随意暴露身份z信息，避免信息泄露给不法分子带来麻烦，可以选择安全可靠的查询方式进行 *** 作。

前后端分离架构带来的好处一搜一大堆，我们来看一下分离后后端接口的安全问题。

前后端分离架构现状：

这样的情况后端api是暴露在外网中，因为常规的web项目无论如何前端都是要通过公网访问到后台api的，带来的隐患也有很多。

1接口公开，谁都可以访问

2数据请求的参数在传输过程被篡改

3接口被重复调用

session和cookie都是客户端与服务端通讯需要提供的认证，当客户端的值和服务器的值吻合时，才允许请求api，解决了第1个问题，但是当攻击者获取到了传输过程中的session或者cookie值后，就可以进行第2、3种攻击了

JWT标准的token包含三部分：

头部用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的算法等

将上面的JSON对象进行 [base64编码] 可以得到下面的字符串。这个字符串我们将它称作JWT的Header

Payload也是一个JSON对象。包含了一些其他的信息

这里面的前五个字段都是由JWT的标准所定义的。

将上面的JSON对象进行 [base64编码] 可以得到下面的字符串。这个字符串我们将它称作JWT的Payload

将上面的两个编码后的字符串都用句号 连接在一起（头部在前），就形成了

最后，我们将上面拼接完的字符串用 HS256算法 进行加密。在加密的时候，我们还需要提供一个 密钥（secret） 。如果我们用 mystar 作为密钥的话，那么就可以得到我们加密后的内容

这一部分叫做 签名

最后将这一部分签名也拼接在被签名的字符串后面，我们就得到了完整的JWT

签名解决了数据传输过程中参数被篡改的风险

一般而言，加密算法对于不同的输入产生的输出总是不一样的，如果有人 对Header以及Payload的内容解码之后进行修改，再进行编码的话，那么新的头部和载荷的签名和之前的签名就将是不一样的。 而且，如果不知道服务器加密的时候用的密钥的话，得出来的签名也一定会是不一样的。

解决了篡改数据的问题，还有第3个问题，那就是攻击者不修改数据，只是重复攻击

比如在浏览器端通过用户名/密码验证获得签名的Token被木马窃取。即使用户登出了系统，黑客还是可以利用窃取的Token模拟正常请求，而服务器端对此完全不知道， 因为JWT机制是无状态的。

可以在Payload里增加时间戳并且前后端都参与来解决：

处理方法如下。

1、如果使用session，首先如果是单例服务可以使用，如果是分布式的得先解决分布式session问题，然后看session处理token，后台登录成功以后获取session，然后将登录的信息缓存后放到session中，以后每次请求不需要携带token，后台可以获取到session并获取到session，如果有自动刷新，后台校验token失效后可再拿refreshtoken刷新access_token，刷新后的token重新缓存，并重新放入session中，放缓存是因为刷新token需要使用到。

2、不使用session，后台生成token并缓存，将token和登录信息给前端返回，前端获取token并存储到cookie或者localstage中，以后的请求头中都设置从cookie中获取的token，后端截取token做校验。

以上就是关于Token 原理解读全部的内容，包括:Token 原理解读、手动生成token有啥弊端吗、shiro（13）-JWT（Token的生成）等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！