对JWT SESSION 的理解

token 的作用是一次性凭证

假设一次会话是 S1 -> B -> S2
S1 跟 S2 商定好 token，那么 S2 如果能接到 S1 的 token，证明此会话必有 S1 参与，不是 B 凭空造的，它防止的是 B -> S2 的流程未经 S1 授权，（或者说防止没请求过 S1 的什么 C -> S2 ）（ CSRF token ）

假设一次会话是 B -> S1 -> S2
这时候 S1 向 S2 出示 token，作用是防止 B 绕过 S1 的代理直接请求 S2 得到结果，此时 token 保证 S2 收到的请求一定是 S1 发起的而不是其它的什么服务器或浏览器本身 （ SSRF token ）

这些都是在不考虑信道，只考虑逻辑情况下的额外安全措施，首先信道不安全的话 token 可被窃取盗用那安全性是白搭，但就算信道安全，恶意代码也可能通过各种方式混入到请求中，比如存在 UGC 内容里，或者 XSS 从接受输入的地方混入了代码，token 主要防的是混入的第三方恶意请求

token 不要放到 url 里面的参数，放到 request header 里面，这样 https 可以加密 这里考虑的就是信道，但是即使这样，如果用户点了什么不该点的东西，导致token泄露，也会出现安全问题。

token 本身不是用来做保密和安全的，先要明白这点

几篇好文章：
1、有关 Session 的那些事儿，希望我这篇冗长的内容能讲清楚
2、JWT+redis 能替代 session 了吗？
3、Stop using JWT for sessions
Stop using JWT for sessions, part 2: Why your solution doesn’t work

上面三篇文章基本可以比较清楚的了解JWT了，但是没有说cookie的安全问题。