我刚刚开始使用Google API和OAuth2。当客户端授权我的应用程序时，我得到一个"刷新令牌"和一个短暂的"访问令牌"。现在每次访问令牌过期时，我可以将我的刷新令牌发布到谷歌，他们会给我一个新的访问令牌。
我的问题是访问令牌过期的目的是什么?为什么不能用一个持久的访问令牌代替刷新令牌呢?刷新令牌是否过期?
请参阅使用OAuth 2.0访问Google api了解有关Google OAuth2工作流程的更多信息。
这是非常具体的实现，但一般的想法是允许提供者发出短期访问令牌与长期刷新令牌。为什么?
- 许多提供商支持安全性非常弱的承载令牌。通过使它们短暂且需要刷新，它们限制了攻击者滥用被盗令牌的时间。
- 大规模部署不希望每次API调用都执行数据库查找，所以他们发出自编码的访问令牌，可以通过解密来验证。然而，这也意味着没有办法撤销这些令牌，所以它们的发布时间很短，必须刷新。
- 刷新令牌需要客户端身份验证，这使其更强。与上述访问令牌不同，它通常通过数据库查找实现。
以下几个场景可能有助于说明访问和刷新令牌的目的，以及在设计oauth2(或任何其他auth)系统时的工程权衡:
Web应用场景
在web应用场景中，你有几个选项:
- 如果您有自己的会话管理，请在会话状态服务的会话状态中根据会话id存储access_token和refresh_token。当用户请求页面时，需要您访问资源，请使用access_token，如果access_token已过期，请使用refresh_token获取新的。
让我们假设有人设法劫持了您的会话。唯一可能的是请求您的页面。
比较1和2:
在1中，access_token和refresh_token仅在授权服务器(在您的示例中是google)和应用服务器之间的线路上传输。这将在一个安全的通道上完成。黑客可以劫持会话，但他们只能与你的web应用程序交互。在第二种情况下，黑客可以拿走access_token，并对用户授予访问权限的资源形成自己的请求。即使黑客获得了access_token，他们也只有很短的时间可以访问资源。
无论哪种方式，refresh_token和clientid/secret都只有服务器知道，因此web浏览器不可能获得长期访问。
让我们假设您正在实现oauth2并在访问令牌上设置长超时:
在1)短访问令牌和长访问令牌之间没有太大区别，因为它隐藏在应用程序服务器中。在2)有人可以在浏览器中获得access_token，然后使用它来长期直接访问用户的资源。
<标题> 移动场景在手机上，我知道有几个场景:
将clientid/secret存储在设备上，并让设备协调获取对用户资源的访问
使用后端应用服务器来保存clientd/secret，并让它执行编排。使用access_token作为一种会话密钥，并在客户端和应用服务器之间传递它。
比较1和2
在1)一旦你在设备上有了client/secret，它们就不再是秘密了。任何人都可以反编译，然后就像你一样开始工作，当然是在用户允许的情况下。access_token和refresh_token也在内存中，可以在受损设备上访问，这意味着有人可以在没有用户提供凭据的情况下充当您的应用程序。在这个场景中，access_token的长度对可黑客性没有影响，因为refresh_token与access_token位于相同的位置。在2)client/secret和刷新令牌都被破坏。在这里，access_token的过期长度决定了黑客可以访问用户资源的时间。
<标题>到期长度在这里，它取决于您的认证系统对access_token到期时间的保护。如果它对用户来说特别有价值，那么它应该是简短的。不值钱的东西，可以更长久。
像google这样的网站不会让refresh_token过期。像stackflow这样的软件就可以。关于过期的决定是用户易用性和安全性之间的权衡。刷新令牌的长度与用户返回长度有关，即将刷新设置为用户返回应用程序的频率。如果刷新令牌没有过期，那么它们被撤销的唯一方法就是显式撤销。正常情况下，登录不会撤销。
希望这篇文章对大家有帮助
除了其他回复:
一旦获得，访问令牌通常与客户端的每个请求一起发送到受保护的资源服务器。这会导致访问令牌窃取和重放的风险(当然，假设访问令牌的类型为"Bearer"(如初始RFC6750中定义的那样)。
这些风险在现实生活中的例子:
-
资源服务器通常是分布式应用服务器，与授权服务器相比通常具有较低的安全级别(较低的SSL/TLS配置，较少的加固等)。另一方面，授权服务器通常被认为是关键的安全基础设施，并受到更严格的加固。
-
访问令牌可能出现在HTTP跟踪、日志等中，这些跟踪、日志等是在资源服务器或客户端上为诊断目的合法收集的。这些跟踪可以在公共或半公共场所(bug跟踪器、服务台等)进行交换。
-
后端RS应用可以外包给或多或少值得信赖的第三方。
最后一个想法，刷新令牌提供很少的保护，如果有的话，对受损的客户端。
本质上是一种安全措施。如果你的应用被入侵，攻击者只能访问短寿命访问令牌，无法生成新的。
刷新令牌也会过期，但它们的寿命应该比访问令牌长得多。
我已经写了一点，因为我今天自己也在思考这个问题。
https://blog.mukunda.com/cat/2023/refreshing-access-tokens.txt本质上，我认为主要的安全性提升只有在刷新令牌不在其生命周期内保持相同时才存在。
假设有人从你的浏览器cookie中窃取了你的令牌，因为他们暂时可以访问你的设备。
如果他们使用刷新令牌，并且刷新令牌更改，那么您有反馈- 您被注销。对于谨慎的用户来说，这似乎是合理的怀疑，然后他们可以采取行动并撤销所有令牌。
如果刷新令牌在每次使用时没有更新，那么很难注意到有人同时访问。(很有可能，如果确实更新了，那么它可能会在攻击者使用它之前从你的设备自动更新。)
如果刷新令牌没有在每次使用时更新，那么我看不到该策略的安全性有任何提高，因为它将紧挨着访问令牌和客户端机密。
那么，为什么要访问令牌?这样您就可以定期检查您的凭据是否有效。
刷新令牌过期吗?是的，但通常几个月后如果你有"记得我"自责。规格中没有过期时间，所以你可以一直使用直到它失效。需要较长时间不受监视会话的服务可能具有秘密凭据，因此它们可以刷新其刷新令牌。
更新:我还浏览了OAuth 2.0规范，并看到了相同的原因，尽管它强调可以在服务器端捕获无效的身份验证反馈。这是一个很好的观点——如果令牌被泄露，服务器可以自动撤销令牌。
如果刷新令牌被泄露，并随后被攻击者和合法客户端使用，其中一方将提供无效的刷新令牌，这将通知授权服务器泄露。