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