使用 cookie 时须要考虑的问题web
由于存储在客户端，容易被客户端篡改，使用前须要验证合法性
不要存储敏感数据，好比用户密码，帐户余额
使用 httpOnly 在必定程度上提升安全性
尽可能减小 cookie 的体积，能存储的数据量不能超过 4kb
设置正确的 domain 和 path，减小数据传输
cookie 没法跨域
一个浏览器针对一个网站最多存 20 个Cookie，浏览器通常只容许存放 300 个Cookie
移动端对 cookie 的支持不是很好，而 session 须要基于 cookie 实现，因此移动端经常使用的是 tokenredis
使用 session 时须要考虑的问题数据库
将 session 存储在服务器里面，当用户同时在线量比较多时，这些 session 会占据较多的内存，须要在服务端按期的去清理过时的 session
当网站采用集群部署的时候，会遇到多台 web 服务器之间如何作 session 共享的问题。由于 session 是由单个服务器建立的，可是处理用户请求的服务器不必定是那个建立 session 的服务器，那么该服务器就没法拿到以前已经放入到 session 中的登陆凭证之类的信息了。
当多个应用要共享 session 时，除了以上问题，还会遇到跨域问题，由于不一样的应用可能部署的主机不同，须要在各个应用作好 cookie 跨域的处理。
sessionId 是存储在 cookie 中的，假如浏览器禁止 cookie 或不支持 cookie 怎么办？ 通常会把 sessionId 跟在 url 参数后面即重写 url，因此 session 不必定非得须要靠 cookie 实现
移动端对 cookie 的支持不是很好，而 session 须要基于 cookie 实现，因此移动端经常使用的是 token跨域
使用 token 时须要考虑的问题浏览器
若是你认为用数据库来存储 token 会致使查询时间太长，能够选择放在内存当中。好比 redis 很适合你对 token 查询的需求。
token 彻底由应用管理，因此它能够避开同源策略
token 能够避免 CSRF 攻击(由于不须要 cookie 了)
移动端对 cookie 的支持不是很好，而 session 须要基于 cookie 实现，因此移动端经常使用的是 token安全
使用 JWT 时须要考虑的问题服务器
由于 JWT 并不依赖 Cookie 的，因此你可使用任何域名提供你的 API 服务而不须要担忧跨域资源共享问题（CORS）
JWT 默认是不加密，但也是能够加密的。生成原始 Token 之后，能够用密钥再加密一次。
JWT 不加密的状况下，不能将秘密数据写入 JWT。
JWT 不只能够用于认证，也能够用于交换信息。有效使用 JWT，能够下降服务器查询数据库的次数。
JWT 最大的优点是服务器再也不须要存储 Session，使得服务器认证鉴权业务能够方便扩展。但这也是 JWT 最大的缺点：因为服务器不须要存储 Session 状态，所以使用过程当中没法废弃某个 Token 或者更改 Token 的权限。也就是说一旦 JWT 签发了，到期以前就会始终有效，除非服务器部署额外的逻辑。
JWT 自己包含了认证信息，一旦泄露，任何人均可以得到该令牌的全部权限。为了减小盗用，JWT的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
JWT 适合一次性的命令认证，颁发一个有效期极短的 JWT，即便暴露了危险也很小，因为每次操做都会生成新的 JWT，所以也不必保存 JWT，真正实现无状态。
为了减小盗用，JWT 不该该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。cookie