问OAuth2.0 response_type和grant_type

EN

授权代码流

(1)向授权端点提出授权请求

(2)接收一个短暂的授权代码。

(3)使用授权代码向令牌端点发出令牌请求

(4)获取访问令牌

隐式流

(1)向授权端点提出授权请求

(2)直接从授权端点获取访问令牌。

​

​

因此，服务器将通过客户端的response_type在GET请求中决定哪个流。

隐式流很方便，但是由于黑客很容易获得访问令牌，所以它的rick很高。如果黑客更改了自己的重定向URL，他可以获得访问令牌。这叫中间攻击。

由于code_chanllenge和code_verifier的存在，使得PKCE的授权代码流更加安全，使客户端和服务器之间进行了双重检查。它调用代码交换的验证密钥，服务器存储code_chanlllenge和code_challenge_mothod，然后当询问access_token时，服务器通过code_chanlllenge和code_challenge_mothod验证code_verifier。

另外两个流是存在密码凭据流和客户端凭据流。

参考文献

所有OAuth 2.0流的图表和电影

使用PKCE的隐式流与代码流

我想在这里补充一点，因为我认为最初的海报是在询问一个特定的案例，而不是整个流程。我认为这是一个很好的问题，OAuth 2.0规范并没有明确针对这个特殊情况。

如果我选择response_type作为“令牌”，而选择grant_type作为“授权_代码”，那么授权服务器将如何运行？

这样的事情并没有什么好的理由。如果客户端在token中使用token，并且客户端遵循OAuth 2.0，这意味着客户机将向authorization端点发送请求。授权服务器重定向用户代理进行某种身份验证，并请求资源所有者的授权。如果一切都成功，客户端将获得一个访问令牌。然后不需要再调用需要grant_type的令牌端点。授权服务器应该将此视为一个完全不同的请求。如果客户端首先使用grant_type of authorization code (这不是遵循OAuth 2.0流)向令牌端点发出请求，那么授权服务器应该响应错误，因为客户端将没有一个authorization code与code参数一起使用。

需要grant_type。值必须设置为"authorization_code“。 需要密码。从授权服务器接收的授权代码。4.1.3

authz服务器没有客户端“以前做过什么”的内存。我的意思是，正如您所提到的，response_type和grant_type是在不同端点上使用的参数。因此，使用这些请求是分开的。发送到authz端点时使用response_type，向令牌端点发送请求时使用grant_type。

如果authz服务器在其令牌端点接收到一个code参数，并将一个类似client_credentials的值作为其值的，则authz服务器确实需要处理一些事情，而且客户端很容易出错。我不认为这个部分在规范中得到了明确的解决，因为code更像是一个无关的参数，但我认为它属于无效的请求错误，因为您可以认为它是一个“不支持的参数”，因为请求中的grant_type是client_credentials，而客户端凭据授予类型不支持该参数：

invalid_request:请求缺少一个必需的参数，包括一个不受支持的参数值(授予类型除外)，重复一个参数，包含多个凭据，使用多个机制对客户端进行身份验证，或者格式错误。5.2