我刚刚开始使用Google API和OAuth2。当客户端授权我的应用程序时,我会获得一个“刷新令牌”和一个短暂的“访问令牌”。现在每次访问令牌到期时,我都可以将刷新令牌发送给Google,他们会给我一个新的访问令牌。
我的问题是访问令牌到期的目的是什么?为什么不能只使用持久访问令牌而不是刷新令牌?
此外,刷新令牌是否到期?
有关Google OAuth2工作流程的详细信息,请参阅Using OAuth 2.0 to Access Google APIs。
这是非常具体的实现,但一般的想法是允许提供商发布具有长期刷新令牌的短期访问令牌。为什么?
在设计oauth2(或任何其他auth)系统时,一些场景可能有助于说明访问和刷新令牌的目的以及工程权衡:
在Web应用程序方案中,您有几个选择:
让我们想象有人设法劫持你的会话。唯一可能的是请求您的页面。
比较1和2:
在1中,access_token和refresh_token仅在授权服务器(在您的情况下为谷歌)和您的应用服务器之间的路上传输。这将在安全通道上完成。黑客可以劫持会话,但他们只能与您的网络应用程序进行交互。在2中,黑客可以将access_token带走并形成他们自己对用户已授予访问权限的资源的请求。即使黑客获得了access_token,他们也只有一个可以访问资源的短窗口。
无论哪种方式,只有服务器知道refresh_token和clientid / secret,使得从Web浏览器无法获得长期访问。
让我们假设你正在实现oauth2并在访问令牌上设置一个长时间超时:
1)短访问令牌与长访问令牌之间没有太大区别,因为它隐藏在应用服务器中。在2)有人可以在浏览器中获取access_token,然后使用它直接访问用户的资源很长一段时间。
在移动设备上,我知道有几种情况:
比较1和2
1)一旦你在设备上拥有clientid / secret,他们就不再是秘密了。任何人都可以反编译,然后在用户的许可下开始表现,就像他们一样。 access_token和refresh_token也在内存中,可以在受感染的设备上访问,这意味着有人可以在没有用户提供凭据的情况下充当您的应用。在这种情况下,access_token的长度对hackability没有影响,因为refresh_token与access_token位于同一位置。 2)clientid / secret和刷新令牌都受到了损害。在这里,access_token到期的长度决定了黑客可以访问用户资源多长时间,如果他们掌握了它。
这取决于您使用auth系统确保您的access_token到期时间有多长。如果它对用户特别有价值,那么它应该很短。价值不高的东西可能更长。
有些人喜欢google不会使refresh_token过期。有些像stackflow那样。到期的决定是用户轻松和安全之间的权衡。刷新令牌的长度与用户返回长度相关,即将刷新设置为用户返回应用程序的频率。如果刷新令牌没有到期,则撤销它们的唯一方法是使用显式撤销。通常,登录不会撤销。
希望相当长的帖子是有用的。
它本质上是一种安全措施。如果您的应用受到攻击,则攻击者只能访问短期访问令牌,无法生成新令牌。
刷新令牌也会过期,但它们应该比访问令牌长得多。
除了其他答复:
一旦获得,访问令牌通常与客户端到受保护资源服务器的每个请求一起发送。这会导致访问令牌窃取和重放的风险(当然,假设访问令牌属于“承载”类型(如初始RFC6750中所定义)。
在现实生活中这些风险的例子:
另一方面,刷新令牌通常仅通过线路传输两次,并且始终在客户端和授权服务器之间传输:一次由客户端获取,一次由客户端在刷新期间使用(有效地“到期”之前刷新)令牌)。这是截获和重播的绝佳机会。
最后一点,Refresh Tokens对受到攻击的客户提供的保护很少(如果有的话)。