我正在尝试构建一个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'，授权服务器将如何操作？由于授权码授权应该返回一个代码而不是一个令牌，在这种情况下，服务器将如何操作？
类似地，如果我选择“代码”响应类型和“隐式”授权类型，会有什么行为？
2条答案
按热度按时间ie3xauqp1#
授权代码流
(1)向授权端点发出授权请求
(2)接收短期授权码
(3)使用授权代码向令牌端点发出令牌请求
(4)获取访问令牌
隐式流
(1)向授权端点发出授权请求
(2)直接从授权端点获取访问令牌。
因此服务器将通过客户端的GET请求中的
response_type来决定哪个流。隐式流虽然方便，但由于黑客很容易获得访问令牌，因此风险很高，如果黑客改变自己的重定向URL，就可以获得访问令牌，这称为中间攻击。
PKCE的授权代码流由于code_challenge和code_verifier在客户端和认证服务器之间进行双重检查而更加安全，它被称为代码交换的证明密钥（Proof Key for Code Exchange，PKCE）服务器存储
code_chanlllenge和code_challenge_mothod，然后当请求access_token时，服务器通过code_chanlllenge和code_challenge_mothod来验证code_verifier。另外两个流程是密码凭证流程和客户端凭证流程
参考文献
Diagrams And Movies Of All The OAuth 2.0 Flows
隐式流与使用PKCE的代码流
qlvxas9a2#
我想在这里补充一点，因为我认为最初的发帖者问的是一个特定的情况，而不是整个流程。我认为这是一个很好的问题，the OAuth 2.0 spec没有明确解决这个特定的情况。
如果我选择response_type为'token'，但选择grant_type为'authorization_code'，授权服务器将如何运行？
这种情况并没有什么好的原因。如果客户端使用
response_type和token，并且客户端遵循OAuth 2.0，这意味着客户端正在向authorization端点发送请求。授权服务器重定向用户代理以进行某种身份验证并向资源所有者请求授权。如果一切都成功，客户端获得一个访问令牌。不需要再调用需要grant_type的令牌端点。授权服务器应该将此视为一个完全不同的请求。如果客户端首先使用authorization code的grant_type向令牌端点发出请求（它不遵循OAuth 2.0流程），授权服务器应该响应一个错误，因为客户端没有authorization code与code参数一起使用。需要grant_type。值必须设置为“authorization_code”。
code REQUIRED。从授权服务器接收的授权代码。4.1.3
authz服务器没有客户端“以前做过什么”的记忆。我的意思是，正如你提到的，
response_type和grant_type是在不同端点使用的参数。所以使用这些参数的请求是独立的。response_type用于向authz端点发送请求，grant_type用于向令牌端点发送请求。authz服务器 * 确实 * 需要处理的一个问题是，如果它在令牌端点接收到一个
code参数和一个grant_type参数，该参数的值类似于client_credentials。但我认为它福尔斯无效请求错误，因为如果请求中的grant_type是client_credentials，而客户端凭据授权类型不支持该参数，则可以将其视为“不支持的参数”：无效请求：请求缺少必需的参数、包含不支持的参数值（除授权类型外）、重复参数、包含多个凭据、使用多个机制对客户端进行身份验证，或者格式不正确。5.2