如果第三方向 OAuth 提供者发出的请求包含一些将请求与用户相关联的其他数据，例如用户的姓名或 ID，则服务器可以将不记名令牌存储为带有单个盐的常规密码。但是，如果第三方请求没有可识别信息，则服务器可以存储不记名令牌的加盐+散列版本，并为所有不记名令牌共享盐。因为 OAuth 令牌很快过期，所以与可能永不过期的密码相比，唯一的盐几乎没有那么重要。如果令牌在 6-12 小时后过期，攻击者就无法真正破解哈希并使用它来访问用户帐户。然后服务器可以每周左右定期轮换盐以增加安全性。

根据贾斯汀的回答，我正在构建自己的。

如果标记足够长（在我的情况下，它们是 200 个字母数字 ( [A-Za-z0-9]) 字符，则无需对它们加盐。单独散列就足够了，因为复杂性足够高。

如果令牌不够长而无法仅使用散列（或者如果您想坚持对它们进行加盐），您可以稍微修改令牌生成方案：生成一个特定于令牌的主体，而不是生成一个随机令牌。然后将两者连接起来，并将结果作为单个令牌交给消费者应用程序。这本质上是要求 API 客户端也发送用户识别信息，但它方便地嵌入到单个令牌中。

在内部，您在存储之前对实际令牌进行加盐 + 哈希处理，并单独存储特定于令牌的主体。在验证令牌时，您将提交的令牌一分为二，取回实际令牌和特定于令牌的主体。然后可以使用此主体查找可以运行匹配器的加盐+散列的实际令牌。

具体例子：

1. 生成不记名令牌：例如 a0z9B1Y8c2x7
2. 生成一个固定长度的特定于令牌的主体：例如 D3W6e4v5F5
3. 生成盐，例如 aabbccddeeff00112233445566778899
4. Salt+hash 不记名令牌 ( a0z9B1Y8c2x7)，这将导致如下所示：xyzXYZabcABC
5. 将 salted+hashed 令牌与特定于令牌的主体一起存储，即存储一个元组 (xyzXYZabcABC, D3W6e4v5F5)
6. 将令牌和主体的连接提供给用户，以将其视为常规不记名令牌： a0z9B1Y8c2x7D3W6e4v5F5