找不到有关实施OAuth 2刷新令牌持久性的最佳方法的任何指导,以及有关实际存储内容和方式的常见意见.

虽然Taiseer Joudeh有一个关于ASP.NET Web API中的OAuth授权的very good totorial.
这是文章中的RefreshTokens表：

其中：Id – 唯一令牌标识符的哈希,主题 – 用户名,ClientId – 应用程序标识符,ProtectedTicket – 序列化访问令牌.

我想在SO社区的帮助下证明或破坏那里做出的一些决定.
所以这是我的担忧：

>为什么我们要坚持短暂的access_token？到目前为止,我可以想到这种方法的两个原因.首先,当你在任何地方保持用户的访问权限,只是等待某人抓住它们,并重用于不可靠的资源服务器时,可能会出现安全威胁(请记住,他们应该使用相同的算法来对密钥进行serilize / deserialize).其次,一旦决定更改序列化算法的任何部分,就必须关心更新这些持久化的票证.那么,为什么我们在验证client_id和refresh_token而不是从数据库中读取和反序列化后,我们不会简单地在运行时创建新票证？
>如果我们应该坚持使用access_token,应该如何加密？序列化机票上的盐SHA2能否完成工作或有更好的方法？
>为什么hash refresh_token id？它实际上保护了哪种攻击？如果我们将哈希密钥作为refresh_token发送,同时在数据库中保留真正的密钥,那么它会不会更安全？这种方式对refresh_token(猜测随机用户的刷新令牌)的暴力攻击也必须猜测散列算法.

最佳答案 我会尝试更多地阐明这些观点：

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

3 – 如果您的DBA可以访问此表并且他可以看到普通刷新令牌标识符,那么他可以使用grant_type(refresh_token)使用这些刷新令牌标识符简单地获取新的访问令牌