OAuth2.0 response_type 和 grant_type

Question

我正在尝试构建一个Oauth2.0授权服务器，我想了解更多有关response_type和grant_type参数的信息。

从我目前读到的内容来看， response_type 是 /authorize 端点上的查询参数，它的值可以是“token”或“code”，表示授权服务器将使用访问令牌或授权代码进行响应。

grant_type 是 /token 端点上的查询参数，指示授权服务器将使用哪种授权类型来生成令牌或授权代码。授权类型可以是“authorization_code”、“client_credentials”、“implicit”等。

我的问题是，如果我选择response_type为“token”但grant_type为“authorization_code”，授权服务器将如何表现？ 由于授权代码授予应该返回代码而不是令牌，因此服务器在这种情况下会做什么？

同样，如果我选择“代码”响应类型和“隐式”授权类型，将会出现什么行为？

Answer 1

授权代码流程

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

(2) 收到短期授权码

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

(4) 获取访问令牌

隐式流程

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

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

因此，服务器将通过检查 GET 请求中客户端的

response_type

来决定使用哪个流程。

“隐式流程”很方便，但由于黑客很容易获得访问令牌，因此风险很高。 如果黑客更改了自己的重定向 URL，他就可以获得访问令牌。这称为中间人攻击。 由于

code_challenge

和 code_verifier 进行了双重检查，

授权代码流程

更加安全 客户端和身份验证服务器之间。它被称为“代码交换证明密钥”（PKCE）。 服务器存储

code_challenge

和 code_challenge_method，然后，当要求提供

access_token

时，验证

code_verifier

使用

code_challenge

和

code_challenge_method

。还存在其他两个流程，

资源所有者密码凭证流程

和

客户端凭证流程

。 参考资料：

所有 OAuth 2.0 流程的图表和影片

隐式流程与使用 PKCE 的代码流程

我想在这里添加一点，因为我认为原始发帖者询问的是特定案例，而不是整体流程。 我认为这是一个很好的问题，

OAuth 2.0 规范

Answer 2

如果我选择response_type，授权服务器将如何表现 作为“令牌”，但 grant_type 作为“授权代码”？

发生这种情况并没有充分的理由。如果客户端将

response_type

与

token

一起使用，并且客户端遵循 OAuth 2.0，则意味着客户端正在向

authorization

端点发送请求。授权服务器重定向用户代理以进行某种身份验证并请求资源所有者的授权。如果一切成功，客户端将获得访问令牌。然后无需再次调用需要

grant_type

的令牌端点。授权服务器应该将此视为完全不同的请求。如果客户端首先使用

grant_type

的

authorization code

向令牌端点发出请求（不遵循 OAuth 2.0 流程），则授权服务器应返回错误，因为客户端不会有

authorization code 

与

code

参数一起使用。

grant_type
必需的。值必须设置为“authorization_code”。

代码 必需的。从接收到的授权码 授权服务器。

4.1.3

authz 服务器不记得客户端“之前做了什么”。我的意思是，正如您所提到的， response_type

和

grant_type

是在不同端点使用的参数。因此，使用这些的请求是单独的。

response_type

用于发送到 authz 端点时，

grant_type

用于向令牌端点发送请求时。authz 服务器

确实

需要处理的事情，并且可能是客户端容易犯的错误，是如果它收到一个

code

参数和一个

grant_type

参数，其值类似于client_credentials它的令牌端点。我认为规范中没有明确解决这部分问题，因为

code

更像是一个无关的参数，但我相信它属于无效请求错误，因为考虑到

grant_type

，您可以将其视为“不受支持的参数”请求中是

client_credentials

并且客户端凭据授予类型不支持该参数：

无效的请求：
该请求缺少必需的参数，包括
不支持的参数值（授权类型除外），
重复一个参数，包括多个凭据，
利用不止一种机制来验证
客户端，或者存在其他格式错误。

5.2