为什么访问令牌会过期？

Question

我刚刚开始使用Google API和OAuth2。当客户端授权我的应用程序时，我会获得一个“刷新令牌”和一个短暂的“访问令牌”。现在每次访问令牌到期时，我都可以将我的刷新令牌发送给Google，他们会给我一个新的访问令牌。

我的问题是访问令牌到期的目的是什么？为什么不能只使用持久访问令牌而不是刷新令牌？

此外，刷新令牌是否会过期？

有关Google OAuth2工作流程的详情，请参阅Using OAuth 2.0 to Access Google APIs。

Answer 1

这是非常具体的实现，但一般的想法是允许提供商使用长期刷新令牌发布短期访问令牌。为什么呢？

• 许多提供商都支持安全性非常弱的承载令牌。通过使它们短暂存在并需要刷新，它们可以限制攻击者滥用被盗令牌的时间。
• 大规模部署不希望每次API调用都执行数据库查找，因此它们会发出可以通过解密验证的自编码访问令牌。但是，这也意味着无法撤销这些令牌，因此它们会在短时间内发布并且必须刷新。
• 刷新令牌需要客户端身份验证才能使其更强大。与上述访问令牌不同，它通常通过数据库查找来实现。

Answer 2

在设计oauth2（或任何其他身份验证）系统时，有几种情况可能有助于说明访问和刷新令牌的目的以及工程权衡：

Web应用程序方案

在网络应用场景中，您有几个选择：

1. 如果您有自己的会话管理，请在会话状态服务上以会话状态存储access_token和refresh_token。当用户请求访问资源的页面使用access_token时，如果access_token已过期，请使用refresh_token获取新页面。

让我们想象有人设法劫持你的会话。唯一可能的是请求您的页面。

1. 如果您没有会话管理，请将access_token放在cookie中并将其用作会话。然后，每当用户从您的Web服务器请求页面时，都会发送access_token。如果需要，您的应用服务器可以刷新access_token。

比较1和2：

在1中，access_token和refresh_token仅在授权服务器（在您的情况下为谷歌）和您的应用服务器之间的路上传输。这将在安全通道上完成。黑客可以劫持会话，但他们只能与您的网络应用程序进行交互。在2中，黑客可以将access_token带走并形成他们自己对用户已授予访问权限的资源的请求。即使黑客获得了access_token，他们也只有一个可以访问资源的短窗口。

无论哪种方式，只有服务器知道refresh_token和clientid / secret，因此无法通过Web浏览器获得长期访问权。

让我们假设你正在实现oauth2并在访问令牌上设置一个长时间超时：

1）短访问令牌与长访问令牌之间没有太大区别，因为它隐藏在应用服务器中。在2）有人可以在浏览器中获取access_token，然后使用它直接访问用户的资源很长一段时间。

移动方案

在手机上，我知道有几种情况：

1. 在设备上存储clientid / secret，让设备协调获取用户资源的访问权限。

2. 使用后端应用服务器来保存clientid / secret并让它进行编排。使用access_token作为一种会话密钥，并在客户端和应用服务器之间传递它。

比较1和2

1）一旦你在设备上拥有clientid / secret，他们就不再是秘密了。任何人都可以反编译，然后在用户的许可下开始表现，就像他们一样。 access_token和refresh_token也在内存中，可以在受感染的设备上访问，这意味着有人可以在没有用户提供凭据的情况下充当您的应用。在这种情况下，access_token的长度对hackability没有影响，因为refresh_token与access_token位于同一位置。 2）cli​​entid / secret和刷新令牌都受到了损害。在这里，access_token到期的长度决定了黑客可以访问用户资源多长时间，如果他们掌握了它。

到期长度

这取决于您使用auth系统确保您的access_token到期时间有多长。如果它对用户特别有价值，那么它应该很短。价值不高的东西可能会更长。

像谷歌这样的人不会使refresh_token过期。有些像stackflow那样。到期的决定是用户轻松和安全之间的权衡。刷新令牌的长度与用户返回长度相关，即将刷新设置为用户返回应用程序的频率。如果刷新令牌没有到期，则撤销它们的唯一方法是使用显式撤销。通常，登录不会撤销。

希望相当长的帖子很有用。

Answer 3

它本质上是一种安全措施。如果您的应用受到攻击，攻击者将只能访问短期访问令牌而无法生成新令牌。

刷新令牌也会过期，但它们应该比访问令牌长得多。

Answer 4

除了其他回复：

获取后，访问令牌通常与客户端向受保护资源服务器发出的每个请求一起发送。这会导致访问令牌窃取和重放的风险（当然，假设访问令牌类型为＃34; Bearer＆＃34;（在初始RFC6750中定义）。

现实生活中这些风险的例子：

• 资源服务器通常是分布式应用程序服务器，与授权服务器相比通常具有较低的安全级别（较低的SSL / TLS配置，较少的强化等）。另一方面，授权服务器通常被视为关键的安全基础架构，并且会受到更严重的强化。

• 访问令牌可能会显示在资源服务器或客户端上为诊断目的合法收集的HTTP跟踪，日志等中。这些痕迹可以在公共场所或半公共场所（虫子追踪器，服务台等）进行交换。

• 后端RS应用程序可以外包给或多或少值得信赖的第三方。

另一方面，刷新令牌通常仅通过电线两次传输，客户端和授权服务器之间始终：一次由客户端获取，一旦客户在刷新期间使用（有效＆＃34;到期＆＃34;先前的刷新令牌）。这是一个极其有限的拦截和重播机会。

最后一想，Refresh Tokens对受到攻击的客户提供的保护很少（如果有的话）。