Web开发茶话会_登陆token

《Web开发茶话会》系列文章的专注于Web开发过程中的重点难点，采取：应用示例+分析+小试牛刀的模式，让读者先有个感性认知，再分析解释知识点，最后抛出一个两个问题，加深理解。此系列文既谈技术，也谈“风月”，请读者备好茶水。

应用示例：

开发一个前后端分离的Web系统，活跃用户可以一直访问系统资源

示例中，活跃用户能够一直访问系统资源，工作过程如下：

• 用户输入账号密码登陆
• 活跃用户持续访问系统资源
• 非活跃用户重新操作时会重定向到登陆页面

 

分析：

session验证

传统的登陆方式是采用Session验证。用户首次登陆后服务器端会生成session，同时向客户端返回sessionId（字符串），浏览器将sessionId存入Cookie中，并被自动加入每次请求头中。但是这种方式有两个主要问题：

1. 服务器压力增大
2. 扩展性不强

针对问题1，session被保存在内存中，同时登陆的用户越多，给服务器端造成的压力越大。

针对问题2，为了解决问题1中单服务器的性能瓶颈问题，常采用服务器集群，不同的服务器必须共享用户登陆的状态（session同步问题）

 

token验证

为了避免session验证的两个问题，我们采用当下流行的token验证。用户首次登陆后服务器端会生成token（字符串），同时将其返回给客户端，一般的方式是将token存入浏览器localStorage中，并带入请求。看起来跟session流程区别不大，但是实际上还是有很大差别的。虽然都是字符串，但是token是按照一定规则生成的字符串。

针对问题1，服务器生成token之后，无需保存，只要能按固定规则对token解码，则说明token有效，因此服务器压力小

针对问题2，任何服务器根据固定规则均能对token解码，因此扩展性强

 

存cookie还是存localStorage？

其实这个只是存储方式的问题，笔者认为是都可以的，不少文章认为两者安全性有差别，但是从安全性来说，两者均会有CSRF风险，cookie的XSS风险更大，但也通过设置HttpOnly、secure、path和domain提高安全性

 

需要几个token？

我们确定了使用token验证，那么需要几个token？别人都说两个token，那么一个token就不行吗？答案是不行，试想一下，哪天你永不失效的token泄漏了，后果是不是有点酸爽。所以一般采用“双token”，它能在提高安全性的同时，还能做到token无感知续期，提高用户体验

 

“双token”怎么工作？

• 用户登陆系统，服务端返回accessToken和refreshToken，前者时效短，后者时效长
• 用户是活跃的，持续访问系统，accessToken和refreshToken都会刷新
• 用户是非活跃的，再次访问系统，refreshToken失效，服务端返回特定状态码，系统重定向至登陆页面
   

小试牛刀：

1. token有状态吗
2. 登陆token到底是什么

问题1：token有状态吗

解答：token最大的特点就是无状态，与之对应的是session记录了用户登陆状态。任何人和机器，只要按照固定规则成功解码token，均说明token有效

 

问题2：登陆token到底是什么

解答：登陆中常用的token全称是JSON Web Token（JWT），它实际上是将JSON对象按照特定规则编码成的字符串

 

参考：

1. 为什么使用token？session与token的区别
2. 看我如何通过XSS窃取localStorage中的JWT
3. JSON Web Token（JWT）