为什么选择 token 的方式而不用 session？

首先我们看一下基于 session 的登陆会遇到什么问题。

• 我们可能有多个后端

  • 比如现在的 XX项目，有多个后端：3 个 django 后端，1 个 java 后端。 只有一个前端，后端都是在同一个域名下，所以前端发送给后端的 sessionid 其实都是一样的，那么为了实现共享登陆的状态，必须实现多服务器共享 session.那么如何实现多服务器共享 session?
  • 解决 session 的共享的方案通常是把这个 sessionid 存储在 cache（对外暴露的是键值对的形式），比如第三方存储系统 redis，Django 中在 settings.py 中配置 SESSION_ENGINE = ‘django.contrib.sessions.backends.cache’
  • 对于都是 Django 的后端，其实问题不大，因为 sessionid 在存储的时候，都是经过编码过的，编码的原因主要是因为数据都有自己的数据结构，而存储可能需要按照一定的格式，Django 在存储的时候是将 sessionid 经过 base64 转码转成 pickle 格式，而 java 是不认识 pickle 格式的（或者说我们没必要去实现这个功能的），所以一般情况下，Java 是没办法和 python 共享 session 的。

• 我们可能有多个前端（其实这一块没有太明白）

  • 多个前端，域名不一样，发送请求的时候没办法带上 cookie，用不同的架构（小程序，ios 等），需要模拟浏览器发请求的方式，每次发送请求时，从数据库中取出 cookie 带上，还是不太方便。

基于 session 的局限性，考虑使用 token 来实现验证。 token 验证大体分三步：

• 后端生成 token
• 校验 token 是否是自己签发
• 校验 token 中的信息