前端通过将身份验证令牌（token）设置到请求的 Authorization 标头中，是为了遵循标准的身份验证方案。这种做法有以下几个主要原因：
1. 安全性：将令牌放置在 Authorization 标头中可以增加安全性。将令牌存储在 Cookie 中可能存在一些安全风险，因为 Cookie 可能会在未经授权的请求中被窃取或篡改。通过将令牌放置在 Authorization 标头中，可以减少令牌的泄漏风险，因为令牌不会自动包含在每个请求中。
2. 跨域请求：对于跨域请求，浏览器会根据跨域安全策略限制对 Cookie 的访问。如果身份验证令牌存储在 Cookie 中并且需要在跨域请求中使用，将无法直接访问到 Cookie 中的令牌。通过将令牌放置在 Authorization 标头中，可以解决跨域请求的身份验证问题。
3. 符合标准：使用 Authorization 标头传递身份验证令牌是符合标准的做法。HTTP 协议规范中定义了 Authorization 标头用于传递身份验证凭据，例如基本身份验证和 Bearer 身份验证。这种做法有助于与现有的身份验证方案和框架集成，并提供一致性和互操作性。
尽管后端可以直接从 Cookie 中获取令牌，但推荐的做法是在前端将令牌设置到 Authorization 标头中，以提高安全性、跨域请求的支持性，并与标准的身份验证方案保持一致。
两种方案：
- 将 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 的域名一定要和主域名区分开。
http是无状态协议，取完数据连接维持30－120秒就就断掉了，要想确认授权状态就要在http头加入authorization字段
前端将token设置到Authorization字段可以防止跨站请求伪造(CSRF)攻击。
将token存储在cookie中，黑客可以通过在相同的域中的恶意网站上发送请求来获取并使用该token。例：黑客可以使用跨站请求伪造 (CSRF) 攻击来获取并使用令牌。在这种攻击中，黑客利用恶意网站上的漏洞来向受害者的网站发送请求，并在请求中包含该令牌。如果受害者已经登录到该网站，并且未采取预防措施，则该请求将被视为有效，并为黑客提供了对受害者账户的访问权限。为了防止这种攻击，网站开发人员可以采取一些预防措施。其中之一是在表单或请求中添加一个验证令牌，该令牌仅在客户端和服务器之间传递，并用于验证请求的来源。还可以使用同源策略 (same-origin policy) 来限制网站上的 JavaScript 代码只能与来自同一域的网站通信。
除此之外，使用 HTTPS 也有助于防止 CSRF 攻击，因为它会加密数据传输，并防止攻击者篡改请求。
总之，防范CSRF攻击需要在验证令牌，同源策略和加密传输之间进行平衡，并确保网站具有足够的安全措施来防止未经授权的访问。
另外，设置在请求头的token更加安全，因为它不会被缓存到浏览器或代理服务器的历史记录中，并且在通过 HTTPS 发送的请求中不会被拦截。
将token存储在请求头中，更方便前端进行管理，例如在用户登录或注销时，可以在请求头中直接添加或删除token，而不需要手动管理cookie。
一个具体的例子是，当用户登录成功后，服务器会返回一个JWT（JSON Web Token）。前端可以将JWT存储在请求头的Authorization字段中。
当前端发送请求到后端时，将会在请求头中携带有JWT，后端可以根据这个JWT来验证用户的身份。如果JWT有效，则后端会返回请求的数据，否则返回错误信息。这样，后端就不需要再次验证用户的身份，因为JWT已经验证过了。
这样，前端就可以在每次请求中携带JWT，而不需要在每次请求中都将用户名和密码发送给后端。这样既提高了用户的体验，又提高了系统的安全性。
总之，将token设置到Authorization字段中更安全，方便前端管理，保证了客户端与服务端之间的安全性。
没啥区别，设置auth里可以忽视域名限制。设置cookie里跨域要指定域名