在详细介绍之前，我会说会话 cookie 和 JWT 都适用于您的情况，如果正确实施，两者都是安全的。我个人会选择 JWT，因为它更容易获得最新信息或现成的解决方案。

智威汤逊

JWT 确实是为无状态授权而设计的，但您仍然可以将它们用于会话。您需要特别注意使用访问/刷新令牌模型，您可以在其中跟踪数据库中的活动刷新令牌。

在加密方面，JWT 标准主要有两种实现方式，即 JWS（签名令牌）和 JWE（签名然后加密令牌）。您要记住的是，签名令牌的签名已经确保了令牌的完整性。如果您还在令牌中传递您希望从客户端隐藏的敏感信息，您将只实施 JWE 。然而，JWT 本身并不能解决中间人攻击的问题，因此您应该记住在传输令牌时使用 SSL。

您的 Web 应用程序和移动原生应用程序之间的令牌存储会有所不同。对于移动应用程序，您应该将它们存储在为此目的而设计的操作系统的 Keychain/Keystore（很可能通过包装器）中。另一方面，在浏览器上存储 JWT 的位置仍然是一个颇具争议的话题，因为存储在 webstorage（sessionStorage/localStorage）中容易受到 XSS 攻击，而存储在 cookie 中容易受到 CSRF 的攻击。

据我所知，总体趋势是避免使用网络存储，因为它的攻击面较大，但老实说，我已经看到了这两种方法的示例。对于单页应用程序，您还可以考虑将令牌保存在内存中而不进行持久存储。

会话 Cookie

在不知道您的移动应用程序的详细信息的情况下，很难说，但根据我的经验，如果您使用的是 Google/iOS 提供的 CookieManager/NSHTTPCookieStorage 机制，则应该不会出现您描述的删除 cookie 的问题。

在浏览器上存储 cookie 需要您保护它免受 CSRF 的影响。您应该使用什么保护将在很大程度上取决于您的特定服务器实现和限制，我认为您应该查看OWASP上的资源或提出更具体的问题。

你信任你所有的客户端代码吗？如果是，您可以将会话 ID 存储在本地存储中，并确保在每个 HTTP 请求中提交它们。在您的后端，只需有一个表，其中会话 ID 哈希作为主键，用户 ID 作为外键，以及到期时间。不要保留已删除会话的列表，只需删除该行（或将其标记为已删除）。

cookie 的风险在于，它们会随每个 HTTP 请求一起发送到您的域，即使它来自假客户端。这称为CSRF。除非您有某种 CSRF 保护，否则请避免使用 cookie 并使用本地存储。

当然，如果您不能信任所有客户端代码，那么您将需要另一种解决方案。

此外，如果您使用 HTTPS，那么会话 ID（cookie 或表单提交）将被加密。