token到底存在cookie还是Authorization字段呢？|authorization|cookie|token|代码|插件功能|文章|浏览器

点击下方“JavaEdge”，选择“设为星标”

第一时间关注技术干货！

免责声明~ 任何文章不要过度深思！万事万物都经不起审视，因为世上没有同样的成长环境，也没有同样的认知水平，更「没有适用于所有人的解决方案」；不要急着评判文章列出的观点，只需代入其中，适度审视一番自己即可，能「跳脱出来从外人的角度看看现在的自己处在什么样的阶段」才不为俗人。怎么想、怎么做，全在乎自己「不断实践中寻找适合自己的大道」

无论对前端还是后端，这两种方案都各有利弊，根据需求选用。

1 将 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 也不具备。

网页的图片请求时也会自动带上 cookie：

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

2 将 token 放在请求头里，用 Authorization 字段：

此字段需由 JS 代码写入，请求想要带上Authorization字段，则需用 JS 代码给请求方法添加全局拦截器，因此它天生具备防止 CSRF 的功能。

只有浏览器使用 cookie，而 Node.js 等环境没有 cookie 的（现在小程序也可支持 cookie），只能使用 Authorization；因为此字段完全由 JS 操作；虽然它原生没有提供 cookie 的Secure、Expires等功能，但可通过 JS 代码自行实现。

前端将 token 持久存储，一般存储在 LocalStorage，此时存在 XSS 攻击盗取 token 问题（将 LocalStorage 里的 token 加密可一定避免），而且它无法跨域互通，即使两个网站的一级域名相同也无法互通。

认证规范要求

必须使用Authorization字段，如 JWT，如使用相关认证（尤其是第三方服务），则必须使用此字段。

参考