有两种方法可以获取访问令牌。
- 使用授权码交换
- 使用刷新令牌刷新它
想想看!!
交换和刷新这个词虽然不同,但它们的作用是一样的。
两个动作都需要解析客户端 ID 和客户端密码(或签名)和令牌
我们可以将授权码保存在我们的系统中,然后再次使用授权码来刷新访问令牌,就像刷新令牌一样。
除了授权码过期太快。
所以我想知道为什么 oauth2 的设计者设计了这两个概念,而不是只使用一个概念,或者说只是设计授权码并给它一个很长的过期时间。
恐怕你对oauth2的概念还不太了解。获取访问令牌的方法不止两种,还有更多。每个基本上都称为“授权类型”。我正在描述我在下面部署的用例:
1- 授权码:这类似于您在不同网站上看到的“使用 Facebook 登录”等按钮的流程,允许您使用您的 facebook 等帐户注册/登录。在这里,单击此按钮后,控制权将定向到 Facebook,用户在其中输入其登录凭据。如果成功,授权代码将发送到您在 Facebook 注册为开发人员时输入的任何重定向 URL。然后,您使用此授权代码请求访问令牌服务以获取访问令牌,然后在访问任何 Facebook 网络服务时使用该访问令牌来获取用户的详细信息。
2- 客户端凭据:如果您正在运行自己的 Web 服务并且希望只允许访问有效客户端,那么这就是您将使用的授权类型。例如,您正在运行您的网络服务,现在您想在您自己的本地移动应用程序中使用它,您通过任何应用程序商店分发该应用程序。这将确保只有安装了您的应用程序的人才能访问您的网络服务。
3- 用户凭据:与上述相同,只有在这种情况下,这才允许您对注册用户进行身份验证,然后授予对用户受限服务(如我的帐户等)的访问权限。
4- 刷新令牌:根据设计,访问令牌服务提供访问令牌和刷新令牌。您将使用从此处获取的刷新令牌来刷新过期的访问令牌。本质上,这不会生成新的访问令牌,它只会“刷新”现有令牌。它将为您提供新的访问令牌和刷新令牌并延长到期时间。当此访问令牌过期时,您再次使用上次获取的刷新令牌调用刷新令牌,并在每次令牌过期时不断重复该过程。
根据RFC 6749 10.5授权代码是短暂的和一次性的。因此,您不能一次又一次地使用它们来获取新的授权令牌。
授权码必须是短暂的和一次性的。如果授权服务器观察到多次尝试将授权码交换为访问令牌,授权服务器应该尝试撤销所有已根据受损授权码授予的访问令牌。
这里似乎还存在一些额外的误解,所以我想帮助澄清它们。
访问令牌和刷新令牌之间的区别可以总结如下:
授权代码授予和隐式授予(以及它们的用法)之间的区别有助于说明两者应该如何使用。
一般而言,授权代码授予应优先于隐式授予,除非通过公开实现的客户端(例如,浏览器运行代码)直接访问资源,或者存在无法使用授权代码授予的特定原因(例如、可行性或性能)。这在隐式流的 RFC 定义中进行了解释。
在隐式授予期间,访问令牌会暴露给用户代理,这可能会导致它们受到损害,因为它们不再受服务器应用程序(机密客户端)的控制,否则它们可能会请求受保护的资源。这就是为什么在隐式授权期间不发布刷新令牌的原因。尽管访问令牌可能会暴露,但它们是短暂的。另一方面,资源令牌是长期存在的,可用于检索新的访问令牌。
另一方面,授权代码授予可防止暴露刷新令牌的可能性。在此授权期间,授权服务器发布代码而不是令牌。然后,用户代理将代码传递给客户端应用程序,客户端应用程序与授权服务器交换代码以检索访问和刷新令牌。由于代码交换是在客户端应用程序和受信任的授权服务器之间直接执行的,因此可以安全地发布刷新令牌。
RFC 规范警告说,应该认真考虑在公共客户端与机密(例如,服务器端)客户端中实施授权代码授予的安全含义。“更多 OAuth 2.0 惊喜:刷新令牌”澄清了一些误解,并进一步说明了身份验证代码不应由用户代理直接发送到身份验证服务器以检索刷新令牌的想法,尽管 OAuth 2.0 规范没有技术上规定了这一点。