在RFC 6749中所述的OAuth2.0授权代码授权中，令牌请求根据sec4.1.3需要客户端密钥;但是，授权请求不符合sec4.1.1。
有谁知道为什么？似乎使用客户端密钥进行授权和令牌请求会使进程更安全。
答案 0 :(得分：1)
它们是不同的，因为它们是两种不同类型的请求。 4.1.1
GET / authorize？response_type = code＆amp; client_id = s6BhdRkqt3＆amp; state = xyz ＆amp; redirect_uri = https％3A％2F％2Fclient％2Eexample％2Ecom％2Fcb HTTP / 1.1 主持人：server.example.com
用于向用户显示实际的同意屏幕。
一旦用户接受，则代码将被交换为访问令牌
>HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz
因为您目前位于文档的“授权代码”部分，所以不需要任何秘密。
4.1。授权代码授权
授权代码授予类型用于获取两种访问权限 令牌和刷新令牌，并针对机密客户进行了优化。 由于这是基于重定向的流程，因此客户端必须具备此功能 与资源所有者的用户代理（通常是网络）进行交互 浏览器）并能够接收传入的请求（通过重定向） 来自授权服务器。
授权代码有时被称为Implicit流，因为所需的访问令牌被发送回客户端应用程序而无需授权请求令牌。这使得整个流程非常简单，但安全性也降低了。由于客户端应用程序（通常是在浏览器中运行的JavaScript）不太受信任，因此不会返回用于长期访问的刷新令牌。将访问令牌返回给JavaScript客户端也意味着您的基于浏览器的应用程序需要特别小心 - 想一想可能将访问令牌泄漏到其他系统的XSS（跨站点脚本）攻击。
基本上，用户隐含地信任他们的电脑，因此实际上不需要客户端秘密验证步骤。只有在用户无法访问服务器的服务器端应用程序中才需要客户端密钥，因此服务器必须自行验证。