持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第1天，点击查看活动详情
来了来了，上个月搞了个合作，最近一直在谈方案，持续写文章都耽误了，接下来开更。
token可以放在cookie里，也可以放在请求头。现在主流的当时是放在请求头，用Authorization。
为什么不用cookie，是因为cookie有以下缺点：
-
跨站请求伪造攻击（XSRF 或 CSRF） ：CSRF 攻击只能通过基于 cookie 的会话处理来实现。该属性允许用户决定是否使用Strict或Lax设置SameSite将 cookie 发送到第三方应用程序。严格的设置可以防止 CSRF 攻击，但也会导致用户浏览器体验不佳。
-
扩展问题：由于会话与特定服务器相关联，因此在扩展应用程序时可能会遇到问题。在负载平衡的应用程序中，如果登录用户被重定向到新服务器，现有会话数据将丢失。为了防止这种情况，会话需要存储在共享数据库或缓存中。这增加了每次交互的复杂性。
-
不利于 API 身份验证：API 为经过身份验证的最终用户提供一次性资源，并且不需要跟踪用户会话。在这种情况下，Cookie 无法完美运行，因为它们会跟踪和验证活动会话。同时，令牌在对 API 端点的每个请求中提供具有唯一标识符的身份验证。
-
Cookie 仅在 HTTPS 连接中是安全的：强制执行该Secure标志可确保仅通过加密的 HTTPS 连接发送 cookie。使用 HTTPS 可防止在中间人MITM攻击中泄露会话 ID。
虽然通过设置属性和遵循最佳实践可以使 cookie 变得安全，但如果通过忽略这些步骤会变得很不安全。
将token放在请求头，比如jwt，jwt有以下优点：
- 灵活且易用：JWT 易于使用。jwt的自包含特性可在不查找数据库的情况下实现验证所需的内容。也就是说 JWT 更适合在 API 中使用，因为 API 服务器不需要跟踪用户会话。
- 跨平台能力：由于其无状态特性，所以可以在移动平台和物联网 (IoT) 应用程序上无缝实现，尤其是和cookie 相比。
- 多种存储选项：可以多种方式存储在浏览器或前端应用程序中。
总结一下：
使用cookie还是jwt，取决于业务，在需要跟踪用户交互时，可以使用cookie，如果构建的是API服务或者分布式系统，就应该使用jwt。
