oAuth静默身份验证与刷新令牌和仅HTTP cookie

Question

以某种方式实现无状态身份验证总是让我头疼。

这一次涉及静默身份验证与刷新令牌。
使用刷新令牌似乎discouraged，但是有些参数我并没有真正得到。

如果您使用仅使用http的cookie来存储您的刷新令牌，那到底是什么危险？
攻击者无法使用Javascript访问cookie，如果您使用SSL（应该使用SSL），我真的不明白问题所在。
我阅读的资源总是说“您不应该在客户端中存储敏感数据”。似乎是自动的，但是如果您想消除服务器会话状态的需求，那显然是不可能的。我也没有真正理解为什么，因为没有资源说明如何破解它（我真的很想知道是否有人真的知道）。

我有这个问题的原因是因为使用刷新令牌不仅可以为我提供身份验证。
例如，如果用户丢失了他/她的设备，则删除刷新令牌只会使所有设备（不仅是浏览器）上的所有访问令牌失效，这似乎是用户想要做的事情。
毕竟，当丢失设备时，您需要采取措施保护数据是很有意义的。

因此，“如果攻击者可以访问刷新令牌，他就可以无限刷新您的令牌”这样的说法听起来像是我没有得到的另一个论点。攻击者不应获取刷新令牌。他怎么会得到它？就像说“如果攻击者掌握了您的银行卡代码，他就可以无限地使用您的钱”一样。好吧，如果您丢失了银行卡，您就叫停卡；同样，如果您丢失刷新令牌，则可以将其删除以使所有访问令牌无效。那么，这是一个怎样的论点呢？

您能否弄清楚为什么为什么我不能仅将刷新令牌存储在仅使用HTTP的cookie中，并且静默身份验证流程对此有何改进？

编辑： 请注意，我阅读了其他一些文章，建议通过在仅HTTP的cookie中发送加密的jwt签名，将jwt存储在浏览器中。这些文章获得了很多好评，因此突然可以了。这对我来说意义非零。

编辑评论：

架构非常简单：

• 后端具有REST API的React / Redux SPA
• 需要通过Google，LinkedIn和Github进行社交登录
• 需要在无需用户交互的情况下刷新令牌
• 访问我自己的api资源（最好使用jwt）
• 撤消刷新令牌的能力

我不知道为什么它看起来很复杂（笑）。

Answer 1

刷新令牌广泛用于：

• 服务器端Web应用程序，根据您的建议，它们存储在仅HTTP的cookie中
• 台式机和移动应用程序，它们也可以存储在操作系统安全存储中

刷新令牌不应无限更新，并且通常代表用户会话时间-例如：

• 刷新令牌/用户会话生存期= 12小时
• 访问令牌/ API消息凭证生存期= 60分钟

以上文章中对SPA的关注是，尽管您不打算使用浏览器存储，但浏览器中没有真正的安全存储-因此那里没有问题。

风险之一是用户可能会通过浏览器开发人员工具获取安全cookie并将其重播到API：

• 为减轻这种情况，当然重要的是要确保API具有精心设计的授权-并且用户可以使用令牌进行的操作与他们在UI中可以进行的操作相匹配。

• 另一个风险是CSRF，其中另一个浏览器选项卡中的恶意应用会将相同的cookie发送到您的后端。因此，您需要对此加以防范。

请注意，SPA具有基于Authorization Server cookie的token renewal solution-如果使用SPA，我宁愿使用该选项，而不是发布自己的cookie。