1

我正在阅读有关基于令牌的身份验证的文章。而当我在阅读这篇文章“ Cookies Vs Tokens ”时，我没有理解以下四点（我在引用的每个点下方都提出了我的疑问）

跨域/CORS：cookie + CORS 在不同域之间不能很好地发挥作用。基于令牌的方法允许您对任何域上的任何服务器进行 AJAX 调用，因为您使用 HTTP 标头来传输用户信息。

为什么现在不会出现cors问题？如果浏览器中相邻选项卡中的某个人窃取了您的令牌（因为在该域的 javascript 中有可以清楚地说明令牌的存储位置以及如何检索令牌的代码）并开始发出请求怎么办？还有更多的说法是“cookies + cors”。为什么说 cookie 和 cors 玩的不好？

CDN：您可以从 CDN 提供应用程序的所有资产（例如 javascript、HTML、图像等），而您的服务器端只是 API。

为什么这是基于令牌的身份验证系统的优势？即使我们在进行基于 cookie 的身份验证时，我们也在使用 cdn 对吗？这是因为脚本标签可以以任何方式调用来自其他域的脚本，对吗？

CSRF：由于您不依赖 cookie，因此您不需要保护跨站点请求（例如，您的站点无法生成 POST 请求并重新使用现有的身份验证 cookie，因为不会有） .

如果浏览器中相邻选项卡中的某个人（来自其他域）窃取了您的令牌并开始发出请求怎么办？我也无法理解这一点。

移动就绪：当您开始在原生平台（iOS、Android、Windows 8 等）上工作时，cookie 在使用安全 API 时并不理想（您必须处理 cookie 容器）。采用基于令牌的方法可以大大简化这一点。

完全没看懂。有人可以解释一下，如何？

4

2 回答 2

3

链接的文章写得有点草率，没有正确定义和区分各种概念。

首先，您必须定义“基于令牌”的确切含义。这篇文章没有这样做，但它似乎有 OAuth 2.0 JWT 访问令牌和不记名令牌使用( http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html )。这意味着：

  • 使用承载访问令牌。不记名令牌（与 MAC 令牌的使用相反）的优点是使用简单——客户端需要传递给服务器的只是一个令牌。不利的一面是，任何持有此类代币的人都被视为其合法所有者，因此他可以随心所欲地使用它。

  • 令牌按照特定语法在Authorization HTTP 标头中传递。

然后，您必须定义“基于 cookie”身份验证的真正含义——同样，本文没有这样做。本质上，cookie 只是一种在特定域的客户端和服务器之间来回传递数据的传输机制，而客户端无需明确执行任何操作。所以你真的可以把几乎任何东西都塞进 cookie 中——甚至是 OAuth 2 访问令牌。

作者似乎想到的是服务器端管理的会话，其中会话 id 在 cookie 中传递。

考虑到这些定义，可以回答您的问题：

跨域/CORS：cookie + CORS 在不同域之间不能很好地发挥作用。基于令牌的方法允许您对任何域上的任何服务器进行 AJAX 调用，因为您使用 HTTP 标头来传输用户信息。

确实如此，但出于不同的原因：Cookie 的范围仅限于特定域，因此只要您使用 cookie 在客户端和服务器之间传递会话 id，您就必须将所有服务器放在一个域下。这看起来像是一个限制，但真正的限制在其他地方——当使用服务器端管理的会话时，会话 ID 只对那些有权访问服务器端会话管理的服务器有意义。域外的任何服务器很可能无法理解会话 ID。

但是，JWT 访问令牌是自包含的，也可以由其他方解释。这就是为什么访问令牌非常适合跨域/跨服务调用的原因。

CDN：您可以从 CDN 提供应用程序的所有资产（例如 javascript、HTML、图像等），而您的服务器端只是 API。

是的。但这在实践中并不重要，因为您放入 CDN 中的任何内容很可能首先不需要身份验证——所以这是一种愚蠢的论点。

CSRF：由于您不依赖 cookie，因此您不需要保护跨站点请求（例如，您的站点无法生成 POST 请求并重新使用现有的身份验证 cookie，因为不会有） .

cookie wrt CSRF 的危险在于它们被隐式传递给服务器 - 浏览器将 cookie 添加到请求中，无论触发请求的流氓代码是否良好。

当令牌在 cookie 中传递时，这种危险适用于我们很好的令牌。但是，当它们在标头中传递时（如 Bearer Token Usage 规范定义的那样），这种危险不存在，因为标头需要每次都显式地添加到请求中。这使得这种方法比 cookie 更安全。

但是，当恶意代码可以通过其他方式获取令牌时（例如，因为它是作为 URL 参数传递的（规范允许），仍然可以使用令牌进行 CSRF 攻击。

移动设备就绪：当您开始在本机平台（iOS、Android、Windows 8 等）上工作时，cookie 在使用安全 API 时并不理想（您必须处理 cookie 容器）。采用基于令牌的方法可以大大简化这一点。

处理 cookie 容器通常比设置 OAuth 更容易，所以我不买这个。

于 2015-12-30T10:23:40.837 回答
1

好的，我将尝试以尽可能结构化的方式完成这些：

  1. CORS + Cookies：Cookies 从来没有打算跨域传输。cookie 必须从其来源提交到服务器，跨域 cookie 不存在。如果令牌存储在其中，则无需担心另一个应用程序访问令牌，localstorage因为该令牌是特定于站点的，例如，每个站点都有自己分配的本地存储空间。

  2. 我不确定这个。我假设它们的意思是经过身份验证的 CDN，例如您提供一个令牌来访问资源

  3. 同样，由于其工作原理，令牌不会被邻居偷走localstorage。如果您担心您实际上可以在每次响应时从服务器发出一个新令牌，从而有效地制作一次性使用令牌。这样，即使您的令牌被泄露，它也不太可能起作用。

  4. Cookie 是相当复杂的结构，如果有一天您决定要在移动设备上使用您的 API，那么使用令牌会容易得多，它只是一个字符串（与结构化对象相比）

最重要的区别是令牌是无状态的，而 cookie 不是。Cookie 将包含有关经过身份验证的用户和特定于上下文的数据的信息。另一方面，令牌只是 API 使用者假定可用于访问受限数据的字符串。

于 2015-12-30T07:21:52.227 回答