如何持久化OAuth 2刷新令牌

Question

找不到任何关于实现OAuth 2刷新令牌持久性的最佳方法和关于应该存储什么以及如何存储的共同意见的指南。

虽然Taiseer Joudeh有一篇非常好的关于ASP.NET Web API中OAuth授权的教程。 这是文章中的RefreshTokens表：

其中：Id - 唯一令牌标识符的哈希值，Subject - 用户名，ClientId - 应用程序标识符，ProtectedTicket - 序列化访问令牌。

我想证明或推翻SO社区做出的一些决定。 所以这里是我的担忧：

1.为什么我们要保留短期的access_token？目前我可以想到两个原因反对这种方法。首先，当您在任何地方保存用户的访问票据时，它可能是安全威胁，只等着有人抓住它们，然后重用它们对于不起疑的资源服务器（记住，他们应该使用相同的算法来序列化/反序列化密钥）。其次，一旦您决定更改序列化算法的任何部分，您将不得不关心更新那些持久化的票据。因此，为什么我们不在运行时创建新的票据，一旦验证了client_id和refresh_token，而不是从数据库中读取和反序列化它们呢？

2.如果我们应该保留access_token，那么应该如何加密它？盐+序列化票证上的SHA2是否能胜任，还是有更好的方法？

3.为什么要哈希刷新令牌id？它实际上保护哪些攻击？如果我们在数据库中保留真正的密钥并将哈希键作为refresh_token发送，那么是否会更安全？这样，对刷新令牌（猜测随机用户的刷新令牌）进行暴力攻击将不得不猜测散列算法。

- 2ooom

Answer 1

我会尝试更清晰地解释这些要点：

1和2 - 如果您查看context.SerializeTicket 此处的源代码，您会注意到此受保护的票证是使用默认DPAPI加密的，该加密依赖于服务器machineKey进行加密。因此，如果您从数据库中获取它，除非您有machineKey，否则无法对其进行任何操作。

3 - 如果您的数据库管理员可以访问此表并且可以查看明文刷新令牌标识符，则可以使用grant_type（refresh_token）使用这些刷新令牌标识符轻松获取新的访问令牌。

- Taiseer Joudeh

---

#1. 是的，但任何人仍然可以在“Authorization”头中复制和粘贴ProtectedTicket列值，并获得授权访问资源服务器，该服务器将使用相同的机器密钥对其进行反序列化并在ReceiveContext中使用。这里的问题更多是关于是否在运行时保留访问凭据还是重新生成它。 - 2ooom

#3. 很好的观点，谢谢。如果您将哈希密钥作为“refresh_token”发送，同时保留密钥在数据库中，那么安全性不会更高吗？这样，在“refresh_token”上进行暴力攻击（猜测随机密钥）就必须猜测哈希算法。 - 2ooom

@2ooom 我不会太担心暴力破解刷新令牌，但使用scrypt或其他慢哈希对其进行哈希处理是一个绝佳的想法。 - CodyEngel