这两个我的意思是：
会话身份验证：在会话变量中存储“已通过身份验证”状态。
Cookie 身份验证：在受 HMAC 保护的 cookie 中存储“已通过身份验证”状态。
问题：从安全的角度来看，一种方式与另一种方式相比有什么优势吗？
我似乎为 cookie 方法找到的最佳原因是服务器必须存储更少的数据，这与安全性无关。
额外说明
假设你告诉我使用 cookie 身份验证更好......
我见过很多使用 cookie 身份验证但无法将其与会话链接的 Web 应用程序。这是一个问题，因为他们将用户信息存储在会话中，例如他的访问权限。因此，您可以构建一个简单的攻击，例如在几乎没有权限的自己帐户上登录，然后从管理员那里窃取会话 cookie，然后冒充他。
我的意思是，无论基于 cookie 的方案对会话方法有什么优势，它都失去了它（因为会话管理不善）。在上述场景中，基于 cookie 的方法不会带来任何安全性。
正如您所概述的，我不是 cookie 身份验证的忠实拥护者。
会话身份验证向客户端分配一个随机令牌，该令牌除了作为存储在服务器上的会话信息的指针之外没有任何意义。主要问题是令牌生成的低熵。
但是，cookie 身份验证往往存在更多问题。由于 cookie 中的信息带有敏感数据，因此它必须具有某种 HMAC 解决方案以防止篡改。Ruby on Rails 做到了这一点，他们遇到了密码学问题和代码执行问题。Play 框架做到了这一点，他们遇到了密码学问题和代码执行问题。如果做得好，这样的机制可以工作，但在这两个例子中，弄错可能是灾难性的。
我每次都更喜欢基于会话的身份验证。cookie 不是一个好的选择。
正如@HexTitan 所说，我也不喜欢 cookie 身份验证。（在一定程度上）破坏它的安全性很容易。暴力破解 cookie 直到它泄露一些秘密并不难。
另一方面，你必须确保你的会话有足够的熵。如果他们不这样做，任何攻击者都可以启动到您的服务器的多个连接，获取会话 ID，并查看它们之间的关联。熵差会导致会话预测。
在安全角度之外，您可以在会话中存储比在 cookie 中更多的数据。您还将减少服务器上的流量，因为每个请求都会发回 cookie，如果您的页面有 135 个图像、10 个脚本和 5 个 css 样式表，那么仅针对主页，cookie 将被发回 150 次。
如果存储空间是一个问题，您可以 bzip 或 gzip 会话数据，并减少存储需求。会话生命周期较短（~2 小时）也会有所帮助。例如，PHP 通常每隔几个小时清理一次过期的会话。
我相信这种无法连接到用户会话的问题可以通过在创建 cookie 期间将 TCP 套接字信息作为变量包含在内来克服。但是，由于 cookie 只是一个键/值对，这完全取决于服务器上的具体实现。