如何以一定的安全性实现刷新令牌？

Posted 2023-03-08

【中文标题】如何以一定的安全性实现刷新令牌？

【英文标题】：How to implement Refresh Tokens with some security?

【发布时间】：2016-09-30 15:08:26

【问题描述】：

用户每次登录时，都会得到一个新的access_token 和一个新的refresh_token。

当他的access_token 过期时，他使用他的refresh_token 获得一个新的access_token。

如果攻击者以某种方式访问​​了他的refresh_token...，那么根据 Oauth 2.0 documentation：

授权服务器可以使用刷新令牌 每次访问都会发出一个新的刷新令牌的轮换 令牌刷新响应。之前的刷新令牌无效，但 由授权服务器保留。如果刷新令牌是 受到攻击并随后被攻击者和攻击者使用 合法客户端，其中一个将呈现无效刷新 令牌，它将通知授权服务器违规。

所以基本上，如果任何refresh_token 被使用两次，我会注意到攻击。

但是如果合法用户从不使用他的刷新令牌（被攻击者窃取）怎么办？攻击者将能够在合法用户检测不到的情况下一遍又一遍地登录和刷新。

听起来很罕见？如果你来我家吃饭，用我的电脑登录，我得到了你的 refresh_token 和 access_token，而你再也不会使用这个 refresh_token 怎么办？没有人会注意到这次攻击。

什么可以解决这个问题？

【参考方案1】：

每次用户登录时，他都会获得一个新的 access_token 和一个新的 刷新令牌

客户端应用程序获取这些令牌，而不是最终用户。

攻击者将能够一遍又一遍地登录和刷新，而无需 合法用户能够检测到它

要使用刷新令牌，您还需要客户端的密码。

如果你来我家吃饭并用我的电脑登录会怎样

我永远不会那样做。我没那么粗鲁:) 晚餐吃什么？

【讨论】：

当然我的意思是客户端应用程序！然后，您说“客户的秘密”，但是当它是 javascript 应用程序时，我该如何处理这样的事情？我找不到有关它的资源。至于晚餐，意大利面。

javascript 应用程序应使用不发出刷新令牌的隐式授权类型，因为 javascript 应用程序无法为客户端保密。意大利面很好:)

好的，但是每个移动应用程序如何实现身份验证（无需两次询问凭据）。 Authorization Server 和 Resouce server 是我们搭建的同一个服务器。隐式流意味着没有刷新令牌，那么移动应用程序如何实现身份验证？

我认为他们使用单点登录：通常用户保持登录到他们的身份提供者（例如 facebook）然后（例如）通过 oauth 使用 facebook 的移动应用程序将能够通过隐式授权定期获得新令牌，而无需与用户交互。用户不会被要求登录，因为他们已经登录并且已经同意移动应用使用的范围。

尝试注销您的 IDP（google、twitter、facebook ...），然后查看将它们用于 OpenID 或 Oauth2.0 的任何移动应用程序会发生什么。