这里关于为什么OAuth2访问令牌会过期的接受答案是：
假设我们不支持未加密传输访问令牌，就可以解决第一点。
假设我们可以对可撤销，完全随机的访问令牌执行数据库查找，就可以解决第二点。
对于移动应用，客户端认证无法更加强大，因为“在注册期间获得的client_id和client_secret被嵌入到应用程序的源代码中。在这种情况下，client_secret显然不被视为机密。”（Google）。这消除了第三个问题。例如，授权服务器可以采用刷新令牌轮换的方式，在每次访问令牌刷新响应中颁发新的刷新令牌。之前的刷新令牌将被作废但保留在授权服务器中。如果刷新令牌被破解并且随后由攻击者和合法客户端使用，其中一个人将提供一个作废的刷新令牌，这将通知授权服务器存在安全漏洞。
假设我需要3小时来破解数据包并获取令牌，但是访问令牌只能用两个小时。然后，在我成功地进入你的帐户之前，令牌已经更改了，我必须从头开始。如果令牌是非过期的，则我完全可以访问你的帐户，而你却没有任何办法可以替换它，除非删除令牌并强制重新授权。
OAuth2访问令牌不必过期（或者说它们确实会过期，但可能是多年以后）。
访问令牌可以用一次来从资源服务器获取某些资源，特别是允许用户批准的那些资源。另一方面，刷新令牌允许重复访问。因此，如果没有刷新令牌，就不能在每次访问之间不需要用户交互。
总的来说，令牌有时可能会被同一设备上的其他恶意应用程序或手机上的中间人攻击窃取。如果可以使手机信任一个可疑证书，则SSL是可中间人攻击的。这有时是公司访问内部网络所需的（它们要求接受自签名证书，这使它们能够中间人攻击公司网络上发生的所有加密流量）。因此，假设发送加密令牌意味着它们在途中无法被窃取是危险的。
Bearer令牌本身并不比其他任何形式的令牌弱，这在一些论文中已经得到证明（包括我自己的一篇，我会在找到链接后发布）。然而，在仅当它们所做出的假设是有效的情况下，Bearer令牌才是合适的。通常，Bearer令牌的一个主要假设是令牌可以保密。如果这不是真的，则Bearer令牌不会断言任何安全属性（尽管有些仍然保持）。请参见NIST Level 3 tokens，其中定义了Bearer令牌必须击败的攻击，如OAuth Bearer Tokens所指定的那样。简而言之，Bearer令牌不应该打败令牌的盗窃。
Bearer令牌无法被撤销，这是事实。然而，考虑到访问的通常模式是在获取后立即使用访问令牌，应该相当快地过期访问令牌以防止潜在的滥用，即使当前无法想出滥用案例。令牌存在的时间越长，被盗的可能性就越大。刷新令牌实际上更容易被盗窃，因为它提供了在更长时间范围内重复访问的机会，如果您无法保护客户端ID。OAuth2可以提供对资源的访问，例如可以用于向客户端暴露API一段时间。与单次使用令牌相比，使用刷新令牌可以造成更多的损害。
实际上，可以通过多种方式使客户端身份验证更加安全，例如，在下载时为每个客户端提供不同的密钥。这可以防止广义攻击，其中在一个设备上反向工程化令牌会破坏所有客户端实例的安全性。其他潜在的技术包括使用OAuth验证客户端与您的服务器，然后使用您希望访问的授权服务器执行OAuth协议的第二次运行。这样，您就可以让客户端定期更新其密钥，并且让它们都具有不同的密钥，同时不会对Facebook或Google拥有的授权服务器使用的系统造成不必要的负担。
在使用移动应用程序时，长期有效的刷新令牌比具有某种多次使用的承载令牌更安全，即使用户没有采取保护客户端的措施。这是因为用户无法使令牌过期。如果未窃取刷新令牌，并且用户仅希望撤销访问权限，则可以执行此操作。即使用户仅希望撤销访问权限，多次使用的承载令牌也无法被撤销。显然，多次使用的数据库引用令牌可以被撤销，但这不是协议的设计目的，因此对OAuth进行的安全性分析并未涉及此混合系统的安全性。
总之，我建议使用刷新令牌和数据库令牌，因为这是最可能安全的。如果您可以采取任何措施来保护客户端，那就是额外的奖励，但是这种保护所针对的情况很少。如果您确实想要保护客户端，请考虑软令牌（例如Google Authenticator），因为这是一个经受了一些非常聪明的人分析的可靠实现。
AccountManager类来处理令牌和授权，Google的服务已经内置在其中。我认为他们还没有使用应用签名检查，而是采用了客户端凭据方法。应用签名检查是在由Yaniv Inbar主持的2012年Google I/O演讲中宣布的，有趣的部分是在10:41。 - Jan Gerlinger