Security 会话与基于令牌的身份验证

我想知道实现身份验证哪个更安全，为什么？ 基于会话的身份验证还是基于令牌的身份验证

我知道会话也可以用于其他事情，但现在我只对身份验证感兴趣

---

如果使用令牌（甚至不在内存中），服务器端不会存储任何内容，这是真的吗？如果是，那么它如何识别过期的令牌，因为这些令牌也是使用相同的密码签名的？

上面评论中链接的信息安全问题有很多相关信息。尽管如此，在这个问题上提出的一些其他关切问题应该得到解决：

安全 对服务器实现一无所知，这两种方法都同样安全。基于会话的身份验证主要依赖于会话标识符的可猜测性（如信息安全回答中所述，会话标识符本身就是一个非常简单的令牌）。如果会话标识符是一个单调递增的数字id，那么它不是非常安全的，或者它可能是一个不透明的加密强唯一id，具有巨大的密钥空间，这使得它非常安全。您可能会使用您选择的服务器框架提供的会话实现，因此需要对此进行检查。之后，使用会话身份验证，您的服务器实现需要验证服务器存储的会话是否包含相关授权（即用户帐户数据、角色等），因为许多服务器会话框架将默认为根据需要自动生成空会话，会话存在的事实不能作为有效身份验证和授权的充分证据

例如，PHP的内部会话ID生成使用完全随机的288位数字（默认设置），因此它被认为是安全的，OTOH-默认情况下，它自动生成会话，因此必须遵守前面的注释（或者禁用自动会话创建，并确保服务器仅根据需要创建会话）

此外，如果会话ID是使用HTTP URL查询字符串传递的，就像以前的默认值一样，那么会话很容易被盗，这使得整个过程不安全

令牌安全主要基于安全令牌生成：如果服务器以安全的方式生成令牌（即不可猜测和验证），如信息安全回答中所示。一个幼稚的实现（我见过一次）可能是MD5散列一个已知的令牌，比如用户名，这使得它非常不安全，即使是在添加盐时也是如此。当使用加密令牌时，安全性与加密强度密切相关，而加密强度由所使用的算法、密钥长度以及（最重要的）服务器密钥的安全程度决定：如果服务器密钥硬编码到服务器实现中，然后代码是开源的

存储 服务器是否需要存储任何东西通常取决于令牌的实现

许多实现将“API密钥”的概念用作“令牌身份验证”，因此令牌通常只是数据库的某种加密安全ID，记录生成的“API密钥”。这需要存储，但其优点是实现更简单，而且更重要的是能够撤销令牌

另一种方法是让令牌具有其自身的真实性—这允许服务器从本质上将令牌存储卸载到客户端，并将客户端用作数据库—非常类似于HTTP Cookie如何允许服务器将一些存储需求卸载到客户端（通常用于客户机的特定设置，例如用户想要的是亮界面还是暗界面）

这两种模式在信息安全回答中得到了很好的演示：签名和加密

• 签名：令牌是验证器凭据（如用户名）的一些简单编码（如JSON或CSV）以及令牌的过期时间（如果您希望令牌过期-通常是一个好主意，如果您无法撤销令牌），然后服务器使用服务器密码对生成的文本进行签名，并将其添加到令牌中。当客户端提交令牌时，服务器可以从令牌中提取明文，重新签名，并将新签名与提交令牌中的签名部分进行比较-如果它们相同，则令牌有效。验证后，您可能会bly希望对照当前时间检查验证的到期日期。此处的主要缺点是，应注意明文身份验证详细信息不足以让攻击者重新身份验证，否则会损害安全要求。即，不要将密码作为令牌的一部分发送，或发送任何其他内部消息细节

• 加密：通过再次编码所有相关的身份验证详细信息，然后使用服务器机密加密明文并仅提交加密结果来生成令牌。如果加密方案可信，则身份验证详细信息可以包括内部数据，但应小心，因为具有大的加密文本与小签名相比，攻击者可以脱机使用的攻击面更大，弱加密算法在这种情况下的弹性将低于仅签名

在这两种方法中，安全性与加密/签名算法的强度密切相关-弱算法将允许攻击者对服务器机密进行反向工程，并在不进行身份验证的情况下生成新的有效令牌

便条 在我看来，基于加密令牌的身份验证往往比基于会话的身份验证更不安全，因为它依赖于（通常是单一的）开发人员从设计到实现再到部署，一切都做得很好，而基于会话的身份验证可以利用现有的实现来完成大部分繁重的工作，在这些工作中很容易找到高性能的应用程序