我们正在开发一个新项目，我们是两个主要开发人员，并且在如何使用令牌保护服务器与客户端之间的通信方面处于十字路口。

第一个建议：（一次性令牌AKA静态令牌）

1. 客户端通过向api发送用户名和密码以及current_time（此变量也将保存在服务器的数据库和客户端中）来请求主令牌，服务器解释输入并呈现哈希令牌（例如： 58f52c075aca5d3e07869598c4d66648）将其保存在数据库中，并将其返回给客户端。

2. 客户端现在保存主令牌，并使用主令牌+身份验证请求中发送的current_time变量创建新的哈希令牌（让我们将此新令牌称为main_token），服务器也将执行相同操作，并使用相同的算法创建相同的令牌。

3. 客户端每次查询服务器API时，都会将main_token发送到服务器，现在服务器会将其中生成的令牌与客户端发送的main_token进行比较，如果匹配，则表示用户是真实的

第二个建议：（动态令牌）

1. 客户端生成两个随机键（$ key1 = rand（10000,90000）; $ key2 = rand（10000,90000）;）在API上的每个请求上，客户端都会使用查询类型创建一个哈希，而两个键分别为一个复杂的算法，然后将这两个密钥+哈希发送到服务器

2. 服务器使用与客户端相同的算法，创建一个哈希，然后将其与客户端发送的哈希进行比较，如果匹配，则服务器继续处理查询

现在的问题是，哪一种是用于保护API请求的最合理，最安全的方法？

我真的很喜欢第一种方法。

• 易于理解和实施
• （据我所知）是安全的
• 这是我过去见过的一种不常见的方法

我没有提到第一件事，请记住第一件事，用于散列令牌的时间戳必须具有非常短的TTL到期时间（如1秒），因此您可以验证消息是否与12小时之前的消息中的相同时间戳和令牌；显然，它将被视为合法，但在这种情况下并非如此。

如果您只是考虑这两个选项，尽管我只是想确保您也考虑了其他方法，因为有很多方法。实际上比我要列出的要多。这些是一些常见的身份验证方法，值得研究，只是看看它们是否更适合您的目的，如果没有其他了解它们，可能会给您一些想法，以帮助您收紧所采用的任何方法。

请注意，我不是安全专家。

OAuth /联合

在这种方法中，您有一个第三方担保人，使用方代码从中要求令牌/证书/您有什么并将其传递给您，这时您要做的就是询问第三方是否给了您钥匙合法。

优点：

• 基于标准
• 别人的问题将在其他人的系统上找到，因此您将发现是否发生了不安全情况
• 您将需要更少的身份验证工作

缺点：

• 您必须与第三方服务商及其API打交道，或者创建并托管自己的“第三方”以将身份验证与主要服务区分开。
• 对于许多服务而言，矫kill过正，但在概念上值得考虑

异步证书

在这里，您可以让客户使用您在创建用户时与他们共享的公共证书来加密他们的通信。在您这一边，您将使用与该用户关联的私钥进行解密。通常，您会以质询-响应来启动通信，以表明您可以按照期望将其识别为自己所声称的身份进行加密/解密。尽管不使用质询响应的“同步”方法是可行的，但它们的安全性略低，并且存在一些时间同步问题，这会使它们变得更棘手。

来自Novell（是的，我知道，Novell吗？是吗？）

令牌使用变量作为基础来生成一次性密码。此变量称为挑战。确定用于生成密码的变量的两种主要方法是异步或同步。

通过异步或质询-响应方法，服务器软件向令牌发送外部质询（随机生成的变量），以供令牌设备进行加密。令牌使用此质询变量，加密算法和共享机密来生成响应-正确加密的密码。

使用同步方法时，用于生成密码的质询变量由令牌和服务器在内部确定。每个设备中的时间计数器，事件计数器或时间和事件计数器的组合用作质询变量的基础。因为令牌和服务器分别从其内部计数器各自内部确定挑战变量，所以使它们的时间计数器和事件计数器保持同步非常重要。因为服务器和令牌很容易不同步，所以大多数实现都允许计数器之间有一定的偏移量。通常，使用这些计数器值的较小范围或窗口来计算密码。但是，如果令牌和服务器在此窗口之外无法同步，

优点：

• 证书具有CA根，这使它们值得信赖且难以伪造
• 操作系统中具有标准设施，可轻松管理和维护证书库
• 精心研究的方法，有关它的很多信息
• 到期日以及各种其他事项都是标准证书的内置功能，它们通常都很健壮

缺点：

• 证书可能很难以编程方式使用
• 取决于您是否需要外部CA，可能不是免费的
• 可能需要手动维护证书存储，以确保配置了预期的根信任

NTLM

不要笑，如果这是较小的或仅限内部使用的服务，并且您在Windows环境中，则使用标准NTLM身份验证来保证访问没有问题。特别是如果您正在使用IIS，这是最简单的方法。在web.config中也易于维护和配置。

优点：

• 极其容易配置，实施和维护

缺点：

• 互操作性最小
• 不足以进行面向公众的身份验证

随机数

在身份验证方法中使用随机数时，您提供了一种在服务上获取随机数的方法。此方法在每个请求上返回唯一的任意字符串或数据段（“随机数”）。现在，对其他方法的每个请求都需要检索随机数，并在该请求的加密算法中使用它。此处的值是服务器跟踪使用的随机数，并且永远不允许重复使用随机数，这完全可以防止重播攻击，因为一旦发出带有一个随机数的请求，就永远不会再次发出带有该随机数的请求。当请求随机数时，它们被添加到可用随机数列表中，因为它们被使用，它们从可用列表移至已用列表中。

优点：

• 阻止重播攻击非常好
• 完全不容易实现或理解

缺点：

• 要求客户对每个请求都提出两个请求（尽管可以通过仅对某些请求要求随机数来减少）
• 需要管理随机数，它应该是事务性的
• 通过要求额外的随机数请求而对性能产生负面影响（交易性进一步增加了使用随机数的资源成本）