Token认证的好处和坏处是什么？

token 这里我们说的token，是指 访问资源的凭据 。使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是 这样的：

1. 客户端使用用户名跟密码请求登录
2. 服务端收到请求，去验证用户名与密码
3. 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
4. 客户端收到 Token 以后可以把它存储起来，比如放在localStorage中
5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
6. 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就放行

1. 好处

那Token相对于Cookie的好处：

• 支持跨域访问: Cookie是不允许垮域访问的，token支持
• 无状态： token无状态，session有状态的
• 去耦: 不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成，只要在 你的API被调用的时候， 你可以进行Token生成调用即可.
• 更适用于移动应用: Cookie不支持手机端访问的
• 性能: 在网络传输的过程中，性能更好
• 基于标准化: 你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在 多个后端库（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如： Firebase,Google, Microsoft）

2 缺陷

说了那么多token认证的好处，但他其实并没有想象的那么神，token 也并不是没有问题。

1. 占带宽
正常情况下要比 session_id 更大，需要消耗更多流量，挤占更多带宽，假如你的网站每月有 10 万次的浏览器，就意味着要多开销几十兆的流量。听起来并不多，但日积月累也是不小一笔开销。实际上，许多人会在 JWT 中存储的信息会更多。
2. 无法在服务端注销，那么久很难解决劫持问题
3. 性能问题
JWT 的卖点之一就是加密签名，由于这个特性，接收方得以验证 JWT 是否有效且被信任。但是大多数 Web 身份认证应用中，JWT 都会被存储到 Cookie 中，这就是说你有了两个层面的签名。听着似乎很牛逼，但是没有任何优势，为此，你需要花费两倍的 CPU 开销来验证签名。对于有着严格性能要求的 Web 应用，这并不理想，尤其对于单线程环境。