2012-07-06 291 views
22

接受的答案在这里为why OAuth2 access tokens expire移动应用程序的OAuth2访问令牌是否必须过期?

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

假设我们不支持访问令牌的非加密传输来处理第一个项目符号点。

假设我们是用细做一个数据库查询对一个revokable,完全随机的访问令牌需要第二个照顾。

对于移动应用程序,客户端认证不能更强,因为“注册期间获得的client_id和client_secret嵌入到应用程序的源代码中,在这种情况下,client_secret显然不被视为秘密。 (Google)。这消除了第三个问题。

那么,什么是在这种情况下分离短暂的访问令牌和长寿命刷新令牌有什么好处?仅仅发布非过期访问令牌并忽略整个刷新令牌部分是否“可以”?

回答

30

刷新令牌和安全的装置的非过期的访问令牌之间的差是到授权服务器一个额外呼叫。

如果攻击者可以访问您的未过期的访问令牌,他可以直接调用您的资源服务器并获取机密数据作为响应。
现在,如果他盗取了你的刷新标记,他首先必须调用授权服务器并接收访问令牌作为响应。然后他可以查询资源服务器的机密数据。

每次使用刷新令牌从授权服务器请求访问令牌时,如果可能,OAuth 2规范(至少是现在的最新草稿)要求服务器为check the client identity and if it is bound to the token

由于具有客户机密的常规方法无法在开放平台上明确标识已安装的应用程序,运行该应用程序的平台必须提供执行此操作的方法。 Google例如要求开发人员签署Android应用程序。当使用Google API Console请求安卓应用程序的凭证时,您必须指定the fingerprint of the certificate you used for signing the application,并且只能获取客户端ID,但不会回应。在发放令牌时,Google可以决定是否由开发者授权应用程序以他的名义申请令牌。

如果您明确无法验证客户端身份,则至少有可能在某些情况下识别刷新令牌被盗。该规范有一个example for this

当客户端身份验证不可能时,授权服务器应该部署其他手段来检测刷新令牌滥用。

例如,授权服务器可以采用刷新令牌轮换,其中随每个访问令牌刷新响应一起发布新的刷新令牌。之前的刷新令牌无效,但由授权服务器保留。如果刷新令牌受到攻击并被攻击者和合法客户端使用,则其中一个会显示一个无效的刷新令牌,该令牌会向授权服务器通知违规情况。

+0

“在发放代币后,Google可以决定是否由开发者授权应用程序以他的名义申请代币。”他们如何做到这一点? Android操作系统是否位于应用程序和网络之间,是否证明应用程序已正确签名? – Thilo 2012-07-19 04:53:03

+2

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

+0

该项目名为[Google Play服务](https://developers.google.com/android/google-play-services/)。 – 2012-07-19 10:28:54

2

与非到期的访问令牌的最大的问题是,有没有一种机制,以取代被盗的令牌。如果我可以访问您的非过期访问令牌,那么我对于该系统来说是有效的。如果令牌是短命的并且过期,那么有一种机制可以替换被盗的令牌和我必须破解令牌的窗口限制。

假设我花3个小时破解一个数据包并获得令牌,但该访问令牌只有两个小时好。然后,当我无法进入您的账户时,令牌已经改变,我必须重新开始。如果令牌没有过期,那么我可以完全访问您的帐户,并且在删除令牌和强制重新授权之后无法取代它。

+3

但是这个问题不适用于刷新令牌,它以与访问令牌相同的方式发布,存储和使用,并且不会很快过期?那么额外的安全性在哪里呢?这种长期存在的刷新令牌是否完全破坏了访问令牌短暂的好处? – Thilo 2012-07-14 00:08:23

+2

刷新标记仅用于获取新的访问令牌,因此曝光较少。刷新令牌仅在SSL加密消息的主体中发送,而不在头中。而刷新令牌还需要client_id和client_secret进行其他验证。因此,刷新令牌泄露的风险比访问令牌的风险要小。 – 2012-07-14 14:48:16

+0

在这个问题中,我已经假设只使用SSL。此外,client_id和client_secret是移动设备流程中的公共信息。在这种情况下,我真的无法看到刷新令牌如何比访问令牌更安全地泄漏(除了可能每三十分钟而不是每三十秒使用一次)。 – Thilo 2012-07-15 00:27:57

-1

OAuth2访问令牌不必过期(或者确实如此,但可能需要很多年)。

访问令牌可以用于从资源服务器获取某些资源,特别是它允许获取用户批准的资源。刷新令牌另一方面允许重复访问。因此,人们不能废除刷新令牌,而不需要每次访问之间的用户交互。

一般来说,令牌有时可能被相同设备上的其他恶意应用程序或手机上的MITM攻击所盗用。如果可以让手机信任狡猾的证书,SSL就可以使用MITM。公司有时需要访问内部网络(他们要求接受一个自签名证书,这允许他们通过公司网络发生MITM所有加密流量,因此假设发送令牌加密意味着他们不会在途中被盗。危险的,

无限制令牌本身并不弱于任何其他形式的令牌本质,如一堆论文(包括我自己的一篇文章中所证明的那样,当我可以将其挖掘出来时,我会发布该链接)。然而,无记名代币只适用于他们所作的假设是有效的假设,令牌可以保密是一般承载代币的主要假设,如果不是这样,则承载令牌不会声明任何安全属性(尽管有些仍然成立),见NIST Level 3 tokens,它定义了持票人令牌必须击败什么攻击,如s在OAuth Bearer Tokens中特化。短承载令牌不应该打败令牌的盗窃行为。

无法撤销无记名令牌,这是真的。然而,鉴于通常的访问模式是在获取后立即使用访问令牌,因此即使当前无法考虑滥用案例,也应尽快终止访问令牌以防止潜在的滥用。令牌越长,它被盗的可能性就越大。刷新令牌实际上更加危险,因为如果您无法保护客户端ID,它会在更长的时间框架内提供重复访问。一般而言,OAuth2可以提供对资源的访问,因此可以用于向客户端公开一段时间的API。使用刷新令牌可以完成更多的损害,而不是单个使用令牌。

客户端身份验证实际上可以通过多种方式更安全,例如,为每个客户端下载不同的密钥。这可以防止在一台设备上对令牌进行反向工程设计,破坏客户端所有实例的安全性的广泛攻击。其他潜在的技术包括使用OAuth验证客户端与您的服务器,然后使用您希望访问的授权服务器执行第二次OAuth协议运行。然后,您可以让客户定期更新密钥,并为他们提供不同的密钥,同时不会给Facebook或Google所拥有的授权服务器所使用的系统带来不必要的负担。

使用移动应用程序时,即使没有采取措施来保护客户端,长寿命刷新令牌也比拥有某种多用途持票者令牌更安全。这是因为用户不能过期令牌。如果刷新令牌没有被盗用,并且用户仅仅希望撤销访问,那么这可以完成。即使用户仅希望撤销访问权限,也不能撤消多用途持票人令牌。一个多用途的数据库引用令牌显然可以被撤消,但这不是该协议的设计目的,因此在OAuth上执行的安全分析并没有说明这个混合系统的安全性。

总之,我会建议使用刷新令牌和数据库令牌,因为这是最可能安全的。如果你能做任何事情来保护客户,这是一个奖金,但这种保护的情况是微乎其微的。如果你确实想要保护客户端的话,可以考虑使用软标记,一个la google authenticator,因为这是一个坚实的实现,经得起一些非常聪明的人的分析。

+0

“访问令牌可以一次性使用”:您有链接吗?我的理解是,它可以无限次地使用,直到它到期。 – Thilo 2012-07-19 23:21:58

+0

“无法撤销无记名令牌,这是真的。”:为什么?如果令牌由数据库中的条目支持,则可以删除该条目。 – Thilo 2012-07-19 23:23:55

+0

根据定义,不记名令牌包含从资源服务器访问资源所需的所有信息,而不必检查数据库。这是一个不记名令牌的重点,它就像一张钞票,仅仅拥有就没有进一步的身份验证就足够了。如果您正在检查数据库,则不再是不记名令牌。访问令牌可以使用一次的事实可以从它包含一个随机数或一次性值的事实中获得。目前的一些实现不检查这一点,但从技术上讲,它们不符合规范。 – jhoyla 2012-07-20 08:40:25

相关问题