这里接受的答案是why OAuth2 access tokens expire：
-
许多提供商支持承载令牌，这些令牌在安全方面非常弱 . 通过使它们短暂存在并需要刷新，它们可以限制攻击者滥用被盗令牌的时间 . （ What does this mean? I take it to mean allow transmission without TLS? Anything else? ） .
-
大规模部署不希望每次API调用都执行数据库查找，因此它们会发出可以通过解密验证的自编码访问令牌 . 但是，这也意味着无法撤销这些令牌，因此它们会在短时间内发布并且必须刷新 .
-
刷新令牌需要客户端身份验证，这使其更强大 . 与上述访问令牌不同，它通常通过数据库查找来实现 .
假设我们不支持访问令牌的非加密传输，则需要处理第一个项目符号 .
假设我们可以对可撤销的数据库进行查找，完全随机的访问令牌负责第二个 .
对于移动应用程序，客户端身份验证不能更强，因为"the client_id and client_secret obtained during registration are embedded in the source code of your application. In this context, the client_secret is obviously not treated as a secret."（Google） . 这消除了第三个问题 .
那么在这种情况下分离短期访问令牌和长期刷新令牌有什么好处呢？仅发出非过期访问令牌并忽略整个刷新令牌部分是“可以的”吗？
3 回答
刷新令牌和非过期访问令牌之间的区别在于安全性是授权服务器的另一个调用 .
如果攻击者获得了对您的 non-expiring access token 的访问权限，他可以直接调用您的资源服务器并获取机密数据作为响应 .
现在，如果他窃取你的 refresh token ，他首先必须调用授权服务器并接收访问令牌作为响应 . 然后他可以向资源服务器查询机密数据 .
每次使用刷新令牌从授权服务器请求访问令牌时，OAuth 2规范（至少是现在的最新草案）要求服务器为check the client identity and if it is bound to the token（如果可能） .
由于使用客户端机密的常规方法无法在开放平台上明确识别已安装的应用程序，因此运行应用程序的平台必须提供执行此操作的方法 . Google例如要求Android应用程序由开发人员签名 . 因此，在使用Google API Console请求Android应用程序的凭据时，您必须指定the fingerprint of the certificate you used for signing the application并且只获取客户端ID，但没有响应的秘密 . 在发行令牌时，Google可以决定该应用程序是否经过开发人员授权以其名义请求令牌 .
如果您无法验证客户端身份，则在某些情况下至少可以识别刷新令牌被盗 . 规范有一个example for this：
非过期访问令牌的最大问题是没有机制来替换被盗的令牌 . 如果我可以访问您的非过期访问令牌，那么我实际上是您的系统 . 如果令牌是短暂的并且到期，那么有一种机制来替换被盗令牌和窗口上的限制我必须破解你的令牌 .
让我们假设我需要3个小时来破解数据包并获取令牌，但访问令牌只有两个小时 . 然后，当我无法进入您的帐户时，令牌已经改变，我必须重新开始 . 如果令牌未过期，那么我可以完全访问您的帐户，除非删除令牌并强制重新授权，否则您无法替换它 .
OAuth2访问令牌不必过期（或者更确切地说，它们会过期，但可能需要很多年） .
可以使用访问令牌来从资源服务器获取某些资源，特别是，它允许获取用户批准的那些资源 . 另一方面，刷新令牌允许重复访问 . 因此，人们无法摆脱使用刷新令牌而无需每次访问之间的用户交互 .
一般而言，令牌有时可能被同一设备上的其他恶意应用程序窃取，或者被手机上的MITM攻击窃取 . 如果可以让手机信任一个狡猾的证书，SSL就是MITM能力 . 公司有时需要访问内部网络（它们需要接受自签名证书，这允许他们对公司网络上发生的所有加密流量进行MITM . 因此，假设发送加密的令牌意味着他们不能在途中被盗危险的 .
持票令牌本身并不比任何其他形式的令牌弱，正如在一堆文件中证明的那样（包括我自己的一篇，当我可以将其挖出时，我会发布链接 . ）但是，持票人令牌只是适用于他们所做假设有效的情况 . 令牌可以保密的假设通常是承载令牌的主要假设 . 如果不是这样，则承载令牌不会声明任何安全属性（尽管有些仍然存在） . 参见NIST Level 3 tokens，它定义了攻击承载令牌必须击败的攻击，如OAuth Bearer Tokens中所述 . 简而言之，承载令牌不应该打败盗用令牌 .
持票令牌不能撤销，这是事实 . 然而，鉴于通常的访问模式是在获取后立即使用访问令牌，即使目前无法想到滥用案例，也应该相当快地使访问令牌过期以防止潜在的滥用 . 令牌周围的时间越长，被盗的可能性就越大 . 事实上，刷新令牌被盗是更危险的，因为如果您无法保护客户端ID，它会在更长的时间范围内提供重复访问 . OAuth2通常可以提供对资源的访问，因此例如可以用于将API暴露给客户端一段时间 . 使用刷新令牌可以实现更多的损害，而不是单个使用令牌 .
事实上，客户端身份验证可以通过多种方式变得更加安全，例如，为每个客户端提供不同的密钥 . 这可以防止在一台设备上对令牌进行逆向工程会破坏客户端所有实例的安全性的通用攻击 . 其他可能的技术包括使用OAuth与您的服务器验证客户端，然后服务器使用您希望访问的授权服务器执行第二次OAuth协议 . 这样，您就可以让客户定期更新其密钥，并为他们提供不同的密钥，同时不会给Facebook或Google拥有的授权服务器所使用的系统带来不必要的负担 .
使用移动应用程序时，即使没有采取措施保护客户端，长期刷新令牌也比使用某种多用途承载令牌更安全 . 这是因为用户无法使令牌过期 . 如果刷新令牌没有被盗，并且用户只想撤销访问权限，则可以这样做 . 即使用户仅希望撤销访问，也不能撤销多用途承载令牌 . 可以明显撤销多用途数据库引用令牌，但这不是协议的设计目的，因此在OAuth上执行的安全性分析没有说明该混合系统的安全性 .
总之，我建议使用刷新令牌和数据库令牌，因为这最有可能是安全的 . 如果你可以采取任何措施来确保客户获得奖金，但这种情况下保护的情况很少 . 如果您确实希望确保客户端考虑使用软令牌，那就是google身份验证器，因为这是一个可靠的实现，可以经受住一些非常聪明的人的分析 .