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

由网友 只有老手 提供的答案：

在Web应用程序中,身份验证（Authentication）和授权（Authorization）是非常重要的安全机制。为了保护用户的信息和应用程序的安全,开发人员必须确保只有经过身份验证和授权的用户才能访问受保护的资源。

在这种情况下,Token是一种常见的身份验证和授权机制。Token是一种令牌,可以用于验证用户身份并授权访问受保护的资源。Token通常是由服务器颁发的,包含一些用户信息和过期时间等信息。Token有多种形式,比如JSON Web Token（JWT）和OAuth Token等。

在Web应用程序中,Token通常会存储在浏览器的Cookie中,以便后端可以直接从Cookie中读取Token。但是,将Token存储在Cookie中存在一些安全问题,因为Cookie可以被窃取或伪造。

为了解决这个问题,前端通常会将Token设置到Authorization头中。Authorization头是HTTP请求头的一种,用于传递身份验证和授权信息。设置Authorization头的好处是可以将Token加密并传输到服务器,确保Token不会被窃取或伪造。此外,设置Authorization头还可以帮助开发人员更好地控制身份验证和授权的逻辑,比如在Token过期时自动重新发放新的Token等。

还是建议不要直接从Cookie中获取Token,而是将Token设置到Authorization头中,以提高安全性和可控性。

直接从Cookie中获取Token存在一些安全问题,因为Cookie可以被窃取或伪造。如果攻击者能够获取到用户的Cookie,就可以伪造Token并冒充用户身份访问受保护的资源。此外,如果Token存储在Cookie中,就无法在前端进行控制,比如在Token过期时自动重新发放新的Token等。

将Token设置到Authorization头中可以提高安全性和可控性。设置Authorization头可以将Token加密并传输到服务器,确保Token不会被窃取或伪造。此外,设置Authorization头还可以帮助开发人员更好地控制身份验证和授权的逻辑,比如在Token过期时自动重新发放新的Token等。

总之,虽然后端可以直接从Cookie中读取Token,但为了保证安全并更好地控制身份验证和授权的逻辑,前端通常会将Token设置到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 的域名一定要和主域名区分开。

由网友 小炜玩科技 提供的答案：

前端将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字段中更安全,方便前端管理,保证了客户端与服务端之间的安全性。

由网友 Java技术 提供的答案：

首先,传递 token 的方式有很多,如 cookie、请求头、请求参数等。将 token 放在请求头中是一种常见的做法。把 token 放在请求头中,可以将 token 与具体的请求数据隔离开来,方便后端程序的解析。

其次,放在请求头中的 token 可以很好的进行安全性的保护。如果把 token 放在请求参数中,那么 token 就会在 URL 中体现,如果 URL 被截获,则 token 就泄漏了。而请求头中的数据不会出现在 URL 中,因此更加安全。

此外,请求头中的数据是不经过缓存的,因此更加安全。在 cookie 中存储的数据是会被缓存的,如果有恶意脚本对 cookie 进行了篡改,那么后端就很难发现问题。

同时,通过请求头传递的 token 更加灵活。在前后端分离的架构中,可能会出现多种请求方式,例如 RESTful API 请求、websocket 请求等,在这些请求中,使用请求头传递的 token 更加方便。

最后,通过请求头传递的 token 更加符合 HTTP

由网友 caiss妈咪 提供的答案：

在前后端分离的架构中,前端负责展示数据和交互,后端负责处理业务逻辑和数据存储等核心功能。前端需要向后端发起请求并获取数据,以便展示在网页上。而要准确地对用户身份进行验证、鉴权等操作,就需要使用token这种身份验证工具。

在提供API的时候,前端为了防止被攻击,在发起请求时需要经过身份认证,必须将token作为请求的授权标识放到Authorization请求头中。后端接收到前端请求时,会根据Authorization中所带的token,来确认用户的身份和相应的权限,确认通过后才会执行请求的具体操作。这是一种常见的网络请求认证机制。

当后端可以直接从cookie里取到token时,为什么仍然需要前端将token设置到Authorization中呢？主要原因是：

1. 安全性问题

当前端设置token到cookie中,后端可以直接通过cookie获取token,但这样存在一定的安全隐患。一旦token泄露,攻击者可以直接获取到用户的身份验证信息,对用户的账号进行危害,甚至威胁到整个系统的安全。因此,前端通过Authorization请求头将token传递给后端能够提高安全性。

2. 前后端分离

为了遵循前后端分离的设计理念,前端和后端是分离的,各自独立开发和部署。前端需要采用跨域请求方式获取后端资源,然而浏览器会自动带上cookies,但是跨域请求时不会发送cookies,因此前端像Authorization中传递token比使用cookies更加符合跨域请求的要求和安全性。

3. 可控性问题

为了避免token泄露问题,后端应该以某种方式将token发送给前端,在前端的交互请求中包含了token,也使得后端可以更好的控制token的维护,当然cookie里的token也可以是通过后台控制用户的登录态,后台对用户是否登录进行处理管理操作,但是这样更容易进行 XSS 攻击,泄露用户token。

总之,前端将token设置到Authorization请求头中,可以提高系统的安全性、符合前后端分离的设计理念、以及便于后端对token进行控制和管理。

由网友 与互联网沾边 提供的答案：

虽然后端可以直接从cookie里取到token,但是从安全性和可维护性考虑,前端通常还是需要将token设置到Authorization header中,而不是直接将token存储在cookie中。

首先,将token存储在cookie中可能存在一些安全风险。例如,如果你的应用程序使用了不安全的传输协议（例如HTTP而不是HTTPS）,那么通过cookie传输的token可能会被拦截和窃取。此外,如果您将token存储在cookie中,那么它将在所有应用程序请求中自动包含,而不仅仅是您希望它包含的那些请求。这可能会增加您的应用程序被攻击的风险。

另外,将token存储在Authorization header中可以使代码更具可维护性。当您的应用程序需要向不同的API发送请求时,您只需要在代码中的单个位置设置Authorization header,而不需要在每个请求中都设置cookie。

最后,将token存储在Authorization header中还使得您的应用程序可以更轻松地与其他认证方案集成,例如OAuth2或JWT。这些方案通常都需要将token存储在Authorization header中,因此将token存储在此位置可以使您的应用程序更易于扩展和维护。

由网友 一剪视频 提供的答案：

跨域请求：将token放在cookie中,浏览器在进行跨域请求时可能不会自动携带cookie,这会导致认证失败。而将token放在Authorization头中,可以确保跨域请求时也能携带token。

防止CSRF攻击：CSRF（Cross-Site Request Forgery）攻击是一种网络攻击手段,攻击者利用用户的登录状态发起恶意请求。将token放在cookie中容易受到CSRF攻击,而将token放在Authorization头中可以降低这种风险。

灵活性：将token放在Authorization头中,可以让开发者更灵活地控制token的发送和接收。例如,可以根据不同的API需求,选择性地携带token。

统一认证机制：将token放在Authorization头中,可以实现不同类型的应用（如Web、移动应用等）采用相同的认证机制,方便开发和维护。

由网友 DeveloperPeer 提供的答案：

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