1

因此，我正在尝试为我正在构建的这个 API 尽可能接近地实现 OAuth 2。我正处于需要生成 access_token 的地步，但是我正在尝试找出执行此操作的最佳方法。我读过一个地方，人们正在加密 revenant 信息和 access_token（如过期日期、客户端 ID 等），以防止在每个 API 调用上查找数据库。

我在想这个并想，生成 access_token 的方式如何处理撤销访问？我的意思是使用 OAuth 的优点之一是能够撤销对应用程序数据的访问，如果我只是使用加密数据而不在数据库中查找，如果我撤销应用程序，它仍然可以访问到我的数据，直到至少那个 access_token 过期。

我认为防止在关系数据库中查找的更好方法是将 access_token 存储在键/值数据库（如 redis）中，因为这样会更快一些。这样，如果有人撤销对应用程序的访问权限，它可以删除关系数据库中的记录和键/值数据中的记录。

我是否遗漏了什么，有没有办法对 access_token 使用加密数据，防止数据库查找每个 API 调用，并且可以随时撤销访问？

4

1 回答 1

1

您已经知道这两种方法（数据库中的令牌与自包含令牌）的优缺点，这是您必须做出的选择。大多数提供商都选择自包含令牌，我建议将其作为起点，例如 JWS/JWE。

但是，我认为您可以对其进行一些调整，并通过一个简单的技巧将两个世界中最好的部分结合起来，而不是简单的自包含令牌（我猜大多数提供商可能会这样做）。考虑到令牌撤销是一种例外情况（至少发生的次数比正常令牌操作少得多），您可以只在数据库中保留已撤销令牌的列表. 验证令牌，您可以在已撤销令牌列表中搜索它：如果没有找到，则可以正常使用其签名或加密的内容。这样你仍然有一个数据库，但记录明显更少，查找速度更快。例如，您可以只使用您的键/值数据库，而不是同时使用键/值和关系数据库。如果您预计 API 的流量不会很大，您甚至可以通过将已撤销令牌列表保存在内存中来保存整个数据库查找，例如，在它们过期后定期从列表中清除它们。

于 2013-03-02T18:03:56.860 回答