为什么访问令牌会过期？

Question

为什么访问令牌会过期？

lev*_*evi 205 oauth google-api oauth-2.0 google-oauth

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

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

此外,刷新令牌是否到期？

有关Google OAuth2工作流程的详细信息,请参阅使用OAuth 2.0访问Google API.

Answer 1

Era*_*mer 222

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

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

@Thilo我认为这个想法是访问令牌不必是可以撤销的.正如Eran所指出的,这使得所请求的服务可以决定是否为某个数据库</ em>中的访问令牌查找服务请求<em>.AFAICT,这是分离刷新令牌和访问令牌的真正好处. (5认同)
两个问题:1)对于移动应用程序,客户端身份验证的要求是否会使其更强大？因为client_secret是应用程序源代码的一部分,所以它完全不是秘密.假设访问令牌也仅通过TLS共享(并且您的第一个项目符号点不适用)是否还有额外的安全性？2)假设在我们的场景中只有这一切(只有TLS,没有自编码的不可启动令牌),是否可以发出不会过期的访问令牌？ (4认同)
什么是持票人令牌,它与刷新和访问令牌有什么关系？ (4认同)
访问(承载？)令牌如何短暂存在？如果我使用过期的承载令牌发出请求,则刷新令牌将返回一个新的承载令牌.同样地,如果我从他们的cookie中窃取某人的令牌,并用该令牌欺骗我自己的cookie,我将其发送到服务器,它将刷新并发送给我一个新的.什么阻止它？不要说IP地址甚至MAC,因为这是不合理的. (4认同)
@Suamere，已经解释过了。承载令牌由不接触身份验证数据库的加密过程验证，从而使它们对于频繁的资源访问更加有效。在涉及检查数据库以确保其仍然有效的过程中验证刷新令牌。现在考虑gmail的工作原理。如果有人从意外的地理位置登录到您的帐户，您将收到警报。您可以看到所有可能具有当前有效的刷新令牌的位置。您可以注销所有位置，使所有其他刷新令牌无效。 (2认同)
@klatzib 虽然你说的已经得到解释是对的，而且你有很好的信息，但这并不能代表我的问题的答案。如果我的邻居偷了我的令牌，他/她可以每分钟将它发送给提供者，提供者会很高兴地刷新并每次都给他们一个新的令牌。什么阻止？ (2认同)
@Suamere刷新请求由客户端与常规资源请求分开发出。刷新令牌不包括在常规资源请求中（资源服务器无法刷新令牌！），因此，如果访问令牌被盗然后过期，除非窃贼还设法窃取了刷新令牌，否则窃贼将无法获得新的访问令牌（（仅当访问令牌最初由客户端获取时才发送）。即使这样，他们也需要有效的客户端凭据才能成功刷新。尽管如Eran所述，所有内容均基于OAuth2文档，但实现方式可能有所不同。 (2认同)

Answer 2

Ed *_*kes 30

在设计oauth2(或任何其他auth)系统时,一些场景可能有助于说明访问和刷新令牌的目的以及工程权衡:

Web应用程序方案

在Web应用程序方案中,您有几个选择:

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

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

如果您没有会话管理,请将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,然后使用它直接访问用户的资源很长一段时间.

移动方案

在移动设备上,我知道有几种情况:

将clientid/secret存储在设备上,让设备协调获取对用户资源的访问权限.
使用后端应用服务器来保存clientid/secret并让它进行编排.使用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那样.到期的决定是用户轻松和安全之间的权衡.刷新令牌的长度与用户返回长度相关,即将刷新设置为用户返回应用程序的频率.如果刷新令牌没有到期,则撤销它们的唯一方法是使用显式撤销.通常,登录不会撤销.

希望相当长的帖子是有用的.

Answer 3

Gui*_*ume 10

除了其他回应：

获取访问令牌后，通常将其与客户端的每个请求一起发送到受保护的资源服务器。这会导致访问令牌被窃取和重放的风险（当然，假设访问令牌的类型为“承载”（如初始RFC6750中所定义）。

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

资源服务器通常是分布式应用程序服务器，并且与授权服务器相比通常具有较低的安全级别（较低的SSL / TLS配置，较少的加固等）。另一方面，授权服务器通常被视为关键的安全基础结构，并且需要经过更严格的加固。
访问令牌可能会显示在HTTP跟踪，日志等中，这些跟踪记录是合法收集的，用于在资源服务器或客户端上进行诊断。这些跟踪可以在公共或半公共场所（错误跟踪器，服务台等）进行交换。
后端RS应用程序可以外包给或多或少可信赖的第三方。

另一方面，刷新令牌通常仅通过电线传输两次，并且始终在客户端和授权服务器之间传输：一次是由客户端获取的，一次是由客户端在刷新过程中使用的（有效地“过期”了先前的刷新）令牌）。这是截获和重播的机会非常有限。

最后想到的是，Refresh Token对受感染的客户几乎没有提供任何保护。

Answer 4

Cla*_*ino 9

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

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

但攻击者是否也无法访问刷新令牌？并可以使用它来创建一个新的访问令牌？ (45认同)
@levi,黑客无法使用刷新令牌来创建新的访问令牌,因为需要客户端ID和客户端密钥以及刷新令牌以生成新的访问令牌. (10认同)
@Spike True,但该应用程序是否也嵌入了客户端ID和密码？ (9认同)
所以它提供了一些防止数据包嗅探的保护,只要拦截只捕获普通数据请求(Chuck只获取访问令牌)？听起来有点弱; 黑帽子必须等待一段时间,直到用户请求新的访问令牌,然后他将获得客户端ID,密码和刷新令牌. (9认同)
这可能只是我在这里被延迟,但如果通过SSL发送,则不会增加另一个可能的安全层.我想我假设每个人都知道SSL是什么. (3认同)

归档时间：	14 年，2 月前
查看次数：	100190 次
最近记录：	7 年，9 月前