1. Oauth2s/

从0开始构建一个Oauth2Server服务 20

·57 字·1 分钟· loading
Oauth2 Oauth2 HTTP
demo007x
作者
demo007x

从0开始构建一个Oauth2Server服务 20
#

Access Token 访问令牌
#

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

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

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

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

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

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

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

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

短期访问令牌,无刷新令牌
#

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

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

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

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

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

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

不会过期的访问令牌
#

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

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

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

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

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

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

Related

从0开始构建一个Oauth2Server服务 19
Oauth2 Oauth2 HTTP
Token 编解码令牌提供了一种通过在令牌字符串本身中编码所有必要信息来避免将令牌存储在数据库中的方法。这样做的主要好处是 API
从0开始构建一个Oauth2Server服务 18
Oauth2 Oauth2 HTTP
AccessToken访问令牌是应用程序用来代表用户发出 API 请求的东西。访问令牌代表特定应用程序访问用户数据的特定部分的授权。
从0开始构建一个Oauth2Server服务 17
Oauth2 Oauth2 HTTP
回调地址 Redirect URL重定向 URL 是 OAuth 流程的关键部分。用户授权应用成功后,授权服务器会将用户重定向回应用