cookie 和 localStorage 都是可以接受的选项，许多应用程序都使用它们。您需要了解它们的优缺点，并选择最适合您的用例的方法。

饼干

• 可以设置为httpOnly，这样 javascript 将无法访问。这使得在 XSS 攻击中无法访问令牌。请注意，这并不意味着该应用程序不易受到 XSS 的攻击。这仅意味着即使 XSS 攻击成功，攻击者也无法访问令牌。
• 有必要明确保护您的应用程序免受 CSRF 的影响，因为身份验证信息将随请求自动发送。
• 只能发送到它们的来源（不是说不同域上的 API）。
• 该令牌可能会被该 cookie 中的普通旧会话 ID 替换，因为无论如何您的应用程序可能并不是真正无状态的。它将降低复杂性并提高安全性。
• 不能用于复杂的单点登录场景中的访问令牌存储，身份提供者有自己的来源，并且应用程序与不同域上的多个后端通信。在这种情况下，短期访问令牌通常存储在 localStorage 中，并在httpOnlycookie 中为身份提供者域设置一个长期刷新令牌。

本地存储

• 可以通过 javascript 访问，其中包括成功的 xss 攻击。
• 如果令牌作为请求标头发送，则通常不需要针对 CSRF 的进一步保护（应用程序本身受到保护，因为身份验证信息不会自动发送）。
• 令牌可以发送到不同的来源。这是主要的好处，也是您通常使用 localStorage 或 JWT 的最重要原因。如果您只想将令牌发送到您的单个应用程序源，您可能根本不需要 JWT，并且绝对不想使用 localStorage。

React 是“XSS 安全的”

不是。开发人员可能更难使其易受攻击，但任何中等复杂性的 React 应用程序都极有可能存在 XSS 漏洞。React 对不同形式的 XSS 毫无免疫力。只要开发人员有多种选择将用户输入插入到 DOM 中，就会出现 XSS，因为有时以“使其工作”的方式解决问题是最容易的。Content-Security-Policy如果在您的应用程序中可行，可能会对现代浏览器有所帮助。尽管默认情况下 React 是非常安全的，但确实如此，这意味着通常它会没事的。这是现在任何现代框架的一个相当标准的要求，并不意味着 React 中的 XSS 是不可能的。它是。

最终，存储在httpOnlycookie 中的会话 ID （具有正确实施的会话管理，例如由您的语言或框架提供）通常是最安全的，其次是httpOnlycookie 中的令牌，但它也取决于您的威胁模型和确切的用例。