OAuth 2，无法为“access_token”和“身份验证代码”使用更好的名称吗？

Question

我正在尝试了解OAuth 2：

据我所知，“access_token”和“身份验证代码”非常相似，因为它们代表了最终用户的意愿。唯一的区别是access_token可以单独使用，而“身份验证代码”必须与app_secret一起使用（rfc6749中的client_secret）。

所以在我看来，如果它们有相似的名字，它会澄清很多，例如：

• “full_token”，“strong_token”或“super_token”表示“access_token”，因为它可以单独使用。它非常强大，绝不能通过非安全线传输。 （但可以直接从浏览器发出请求）
• “half_token”，“weak_token”或“normal_token”表示“身份验证代码”，因为它必须与app_secret结合使用。它可以通过非安全线路传输，但由于app_secret永远不应该发送到浏览器，因此永远不能在那里使用它。

因此，将调用相应的授权类型名称：

• “隐式授权类型”的“full_token grant type”
  • 该术语表示直接生成full_token并仅返回给浏览器（因为它在重定向uri的片段（uri的＃-part）中返回，当浏览器进行重定向时，它不包含在内请求（因此即使请求是非安全uri，它也永远不会暴露））。然后，浏览器可以使用它来提取数据，或者可以将其传输到应用服务器（如果应用使用TLS）
• “授权代码授予类型”的“half_token grant type”
  • 该术语表示生成了half_token，应用程序确保它来到应用服务器（安全行不需要）。在app服务器上，它与app_secret一起发送，以从授权服务器中提取数据。 （rfc6749建议首先应该用full_token替换它，但在我看来这不应该是必要的。）

或者我还有其他差异吗？

Answer 1

授权代码不像您的摘要所暗示的访问令牌。特别是，这不准确：＆＃34;唯一的区别是access_token可以单独使用，而＃34;身份验证代码＆＃34;必须与app_secret＆＃34;一起使用。

在OAuth 2.0 获取授权和使用授权是非常不同的，涉及不同的参与者，他们可以获得不同类型的信息。授权代码是握手过程的一部分，授权服务器获得访问受保护资源的权限。然后，生成的访问令牌将发送到资源服务器（不需要知道任何客户端机密或其他凭据），以代表用户访问资源。

所以他们实际上完全不同。

Answer 2

你的理论

  

full_token，half_token，strong_token，super_token

的存在是因为您误解了Access_token和Authorization_code。

Authorization_code是一个短暂的令牌，交换得到Access_token。授权服务器生成Authorization_code并发送回客户端以保护资源所有者的凭证。客户端稍后将此Authorization_code交换为访问令牌。获得access_token后，授权代码将过期，您无法为同一Authorization_code发出另一个access_token。

要访问您的API，您需要在每个请求的头中传递access_token。您无法使用Authorization_code访问您的API。这就是Authorization_code不是half_token的原因。

同样full_token, strong_token, super_token也没有意义，因为我们只有一个access_token。

请参阅Life cycle of Authorization code