移动应用的OAuth2访问令牌是否必须过期?

Thi*_*ilo 24 security access-token oauth-2.0

这里接受的答案是为什么OAuth2访问令牌到期:

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

假设我们不支持访问令牌的非加密传输,则需要处理第一个项目符号.

假设我们可以对可撤销的数据库进行查找,完全随机的访问令牌负责第二个.

对于移动应用程序,客户端身份验证不能更强,因为"在注册期间获取的client_id和client_secret都嵌入在应用程序的源代码中.在这种情况下,client_secret显然不被视为机密." (谷歌).这消除了第三个问题.

那么在这种情况下分离短期访问令牌和长期刷新令牌有什么好处呢?仅发出非过期访问令牌并忽略整个刷新令牌部分是"可以的"吗?

Jan*_*ger 35

刷新令牌和非过期访问令牌之间的区别在于安全性是授权服务器的另一个调用.

如果攻击者获得对您的非过期访问令牌的访问权限,他可以直接调用您的资源服务器并获取机密数据作为响应.
现在,如果他窃取您的刷新令牌,他首先必须调用授权服务器并接收访问令牌作为响应.然后他可以向资源服务器查询机密数据.

每次使用刷新令牌从授权服务器请求访问令牌时,OAuth 2规范(至少是现在的最新草案)要求服务器检查客户端身份以及是否绑定到令牌(如果可能).

由于使用客户端机密的常规方法无法在开放平台上明确识别已安装的应用程序,因此运行应用程序的平台必须提供执行此操作的方法.Google要求Android应用程序由开发人员签名.因此,在使用Google API控制台请求Android应用程序的凭据时,您必须指定用于签署应用程序的证书的指纹,并且只获取客户端ID,但没有任何秘密作为响应.在发行令牌时,Google可以决定该应用程序是否经过开发人员授权以其名义请求令牌.

如果您无法验证客户端身份,则在某些情况下至少可以识别刷新令牌被盗.该规范有一个例子:

当无法进行客户端身份验证时,授权服务器应该部署其他方法来检测刷新令牌滥用.

例如,授权服务器可以采用刷新令牌轮换,其中每个访问令牌刷新响应发出新的刷新令牌.先前的刷新令牌无效,但由授权服务器保留.如果刷新令牌被泄露并随后被攻击者和合法客户端使用,则其中一个将呈现无效的刷新令牌,这将通知授权服务器该违规.

  • 在Android上,你可以使用[`AccountManager`](https://developer.android.com/reference/android/accounts/AccountManager.html)类来处理令牌和授权,谷歌的服务已经内置在那里.我不认为他们已经在使用应用程序签名检查,而是使用客户端凭据方法.签名检查是在[谷歌I/O 2012谈话由Yaniv Inbar](http://www.youtube.com/watch?v=dylFNrvZ_3U)中公布的,有趣的部分是在[10:41](http:/ /www.youtube.com/watch?v=dylFNrvZ_3U&hd=1&t=10m41s). (2认同)

Mar*_* S. 6

非过期访问令牌的最大问题是没有机制来替换被盗令牌。如果我可以访问您的未到期访问令牌,那么我实际上就是该系统的您。如果令牌是短暂的并过期,那么有一种机制可以替换被盗的令牌,并且我必须破解你的令牌的窗口有限制。

假设我需要 3 个小时才能破解一个数据包并获取令牌,但访问令牌仅适用于两个小时。然后,当我无法进入您的帐户时,令牌已更改,我必须重新开始。如果令牌未过期,那么我可以完全访问您的帐户,除非删除令牌并强制重新授权,否则您无法替换它。

  • 但同样的问题是否适用于刷新令牌,它以与访问令牌相同的方式发布、存储和使用并且不会很快过期?那么额外的安全性从何而来?这个长期存在的刷新令牌的存在是否完全破坏了访问令牌短期存在的好处? (6认同)
  • 刷新令牌仅用于获取新的访问令牌,因此暴露较少。刷新令牌仅在 SSL 加密消息的正文中发送,从不在标头中发送。并且刷新令牌还需要 client_id 和 client_secret 进行额外的身份验证。因此,刷新令牌被泄露的风险比访问令牌要小。 (2认同)