从0开始构建一个Oauth2Server服务 <20> Access Token 访问令牌

从0开始构建一个Oauth2Server服务 <20> Access Token 访问令牌_开发人员

Access Token 访问令牌

当您的服务发出访问令牌时，您需要就您希望令牌持续多长时间做出一些决定。不幸的是，没有针对每项服务的一揽子解决方案。不同的选项会带来各种权衡，因此您应该选择最适合您的应用程序需求的选项（或选项组合）

短期访问令牌和长期刷新令牌

授予令牌的一种常见方法是结合使用访问令牌和刷新令牌，以实现最大的安全性和灵活性。OAuth 2.0 规范推荐此选项，并且一些较大的实现已采用此方法。

通常，使用此方法的服务会颁发持续数小时到数周不等的访问令牌。当服务发出访问令牌时，它还会生成一个永不过期的刷新令牌，并在响应中返回该令牌。（请注意，不能使用隐式授权颁发刷新令牌。）

当访问令牌过期时，应用程序可以使用刷新令牌获取新的访问令牌。它可以在幕后完成此操作，无需用户参与，因此对用户来说这是一个无缝的过程。

这种方法的主要好处是服务可以使用自编码的访问令牌，无需数据库查找即可验证。然而，这意味着没有办法直接使这些令牌过期，因此，令牌的到期时间较短，因此应用程序被迫不断刷新它们，从而使服务有机会在需要时撤销应用程序的访问权限。

从第三方开发人员的角度来看，不得不处理刷新令牌常常令人沮丧。开发人员非常喜欢不会过期的访问令牌，因为要处理的代码要少得多。为了帮助减轻这些担忧，服务通常会将令牌刷新逻辑构建到他们的 SDK 中，以便该过程对开发人员透明。

总之，在以下情况下使用短期访问令牌和长期刷新令牌：

• 你想使用自编码访问令牌
• 你想限制泄漏访问令牌的风险
• 您将提供可以对开发人员透明地处理刷新逻辑的 SDK

短期访问令牌，无刷新令牌

如果您想确保用户知道正在访问其帐户的应用程序，该服务可以发布相对较短的访问令牌，而无需刷新令牌。访问令牌可能会持续从当前应用程序会话到几周的任何地方。当访问令牌过期时，应用程序将强制让用户再次登录，这样作为服务的您就知道用户不断参与重新授权应用程序。

通常情况下，如果第三方应用程序意外或恶意泄漏访问令牌，则存在高损坏风险的服务会使用此选项。通过要求用户不断地重新授权应用程序，该服务可以确保在Attacker从服务中窃取访问令牌时潜在的损害是有限的。

通过不发布刷新令牌，这使得应用程序无法在用户不在屏幕前的情况下持续使用访问令牌。需要访问权限才能持续同步数据的应用程序将无法在此方法下执行此操作。

从用户的角度来看，这是最有可能让人们感到沮丧的选项，因为它看起来像是用户必须不断地重新授权应用程序。

总之，在以下情况下使用没有刷新令牌的短期访问令牌：

• 您想最大程度地防止访问令牌泄漏的风险
• 您想要强制用户了解他们授予的第三方访问权限
• 您不希望第三方应用程序离线访问用户数据

不会过期的访问令牌

非过期访问令牌是开发人员最简单的方法。如果您选择此选项，请务必考虑您所做的权衡。

如果您希望能够任意撤销它们，那么使用自编码令牌是不切实际的。因此，您需要将这些令牌存储在某种数据库中，以便根据需要删除或标记为无效。

请注意，即使该服务打算为正常使用颁发不会过期的访问令牌，您仍然需要提供一种在特殊情况下使它们过期的机制，例如，如果用户明确想要撤销应用程序的访问权限，或者如果用户帐户被删除。

对于开发人员测试他们自己的应用程序来说，永不过期的访问令牌要容易得多。您甚至可以为开发人员预先生成一个或多个不会过期的访问令牌，并在应用程序详细信息屏幕上向他们展示。这样他们就可以立即开始使用令牌发出 API 请求，而不必担心设置 OAuth 流程以开始测试您的 API。

总之，在以下情况下使用不会过期的访问令牌：

• 你有一种机制可以任意撤销访问令牌
• 如果代币泄露，你不会有很大的风险
• 您想为您的开发人员提供一种简单的身份验证机制
• 您希望第三方应用程序可以离线访问用户数据

从0开始构建一个Oauth2Server服务 <20> Access Token 访问令牌_开发人员_02