后端可以直接从cookie里取到token，为什么前端还要token设置到Authorization？

关于问题后端可以直接从 cookie 里取到 token，为什么前端还要 token 设置到 Authorization？一共有 5 位热心网友为你解答:

【1】、来自网友【40 也还有点惑】的最佳回答：

http 是无状态协议，取完数据连接维持 30－120 秒就就断掉了，要想确认授权状态就要在 http 头加入 authorization 字段

【2】、来自网友【DeveloperPeer】的最佳回答：

大多数站点为了更好的用户体验，都会使用 cookie 来存储一些用户的信息，一些站点是默认启用的，而一些网站在用户首次访问时，会提示用户是否允许启用 cookie。因此用户是可以控制是否使用 cookie 的。
cookie 是不支持跨域的，站点 A 访问站点 B 时，是不能自动将站点 A 的 cookie 带上的。这在公司间的数据接口访问时，是普遍存在的，这种接口大多都是采用 Authorization header 来实现 auth 认证的。
避免 CSRF ( Cross-site request forgery ), 用户在站点 B 上登录了，恶意的网站 A 在自己的网站上嵌入了恶意的代码，比如伪造了一个领取红包的按钮，但是按钮点击时，却调用的网站的转账接口，因为访问 B 时，会自动带上网站 B 的 cookie, 如果将授权 token，放在 cookie 中，上面的转账请求就变成了合法的请求。

【3】、来自网友【勇敢的火车 aP】的最佳回答：

两种方案：

将 token 放在 cookie 里；
将 token 放在请求头里，用 Authorization 字段。

无论对于前端还是后端而言，这两种方案都是各有利弊的，下面稍微讲几点，实际开发中根据需求来选用即可。

将 token 放在 cookie 里：

前端可以完全不写代码，设置 cookie 可以依赖后端的

Set-Cookie

响应头，同域名的情况下发送所有请求的时候 cookie 也是自动带上的（也有坏处，这样经常会造成网络流量和带宽的浪费，所以 CDN 的域名都是和主站不同的，避免请求带上 cookie 浪费流量）；

在安全性方面，cookie 可以设置

HttpOnly

来保护 cookie 无法被 JS 代码捕获，避免 XSS 等攻击，还可以设置

Secure

来确保只在 https 环境下传输 token；这些能力由浏览器提供，Authorization 无法实现；

但是，cookie 会存在 CSRF 攻击的问题，虽然浏览器厂商在逐步禁止第三方 cookie（似乎推迟到 2024 年了），但是这个问题还是不得不防（如果想使用第三方 cookie，可以在后端响应中设置 cookie 的 SameSite 属性）；

在一级域名相同的情况下，cookie 可以实现跨子域名互通，比如

a.example.com

和

b.example.com

之间可以实现 cookie 互通（设置 cookie 时提供

Domain=example.com

属性），这个能力也是 Authorization 不具备的；

网页中的图片

<img />

请求时也会自动带上 cookie，好处是便于控制网络图片的访问权限，例如网络相册的权限控制可以精确到用户级，这个是 Authorization 做不到的，它必须把 token 放在 url 查询里面才行；缺点：如果网页中的背景图、icon 等资源图片放在相同的域名下，每次请求这些资源图片都会带上 cookie，很浪费带宽和服务器的流量，所以 CDN 的域名一定要和主域名区分开。