我正在与一家实施OAuth的公司合作，目前他们正在提供一段时间为180秒的access_token。这对我来说似乎很短暂，所以我试图弄清楚access_token的典型生命周期是什么，与其他公司在网络上做的一样。
我在网上看到：
所以在我看来，180秒太短了，因为它会迫使开发人员不断地使用refresh_token来请求新的access_token。
有什么建议吗？
编辑：起初我问的是“OAuth access_token的合理续航时间是什么？＆＃34;”。我已经将问题改为＆＃34; OAuth access_token的典型生活时间是什么？＆＃34;，因为我认为这更接近我的实际意思。
答案 0 :(得分：3)
简短回答：
什么是合理的取决于公司政策及其OAuth实施。
长答案：
访问令牌的生命周期实际上取决于令牌的供应商，即您的合作伙伴公司的授权服务器及其政策。
我同意3分钟很短但公司的安全策略可能要求在撤销某些权限或删除帐户时，基于这些权限授予访问权限的客户端的访问权限将在不超过3分钟内被禁用。事实上，这是以相当大的网络和处理开销为代价的，这是在（希望）计算出来的。
该决定的成本（如：开销）也取决于令牌本身的用法。它很少使用但总是处于突发模式，开销可能相对较低。如果它经常使用但每次只用于一次API调用，则开销相对较大，因此成本较高。
大多数环境不需要立即删除当场的所有委派访问权限，并且发现处理至少1小时的延迟是可以负担得起的。
另一方面，Twitter和Facebook正在以这样的方式实施OAuth，即他们可以负担长期访问令牌：当资源服务器收到访问令牌时，将检查与发出令牌的帐户相关联的权限。当然，出于性能原因，资源服务器将缓存这些结果（为了讨论，比如持续3分钟），但实际上会产生相同的结果，将“刷新开销”推送到资源服务器而不是客户端。 （请注意，这有点违背了使用结构化自包含访问令牌（如JWT）的目的）。
如果您不需要/想要在合理范围内再次明确地验证您的客户端，Twitter和Facebook的方法是有效的。由于Twitter和Facebook也不经常对用户进行身份验证，因此这种方法对他们有意义。
我想你可以说每个用例都不同：这一切都取决于你想要什么以及如何实现它。您的公司和Facebook可能无法比较，因为它们具有不同的令牌，资源服务器实施以及对客户端（和用户）身份验证的限制。