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