OAuth2.0中response_type与grant_type不匹配时授权服务器的行为

首先明确两个参数的核心角色（符合OAuth2.0规范的基础定义）：

• response_type是/authorize端点的必填参数，直接指定该端点返回的凭据类型：code对应授权码，token对应访问令牌
• grant_type是/token端点的必填参数，指定客户端请求令牌时采用的授权流程类型

需要注意的是：这两个参数分属不同的端点，不会同时出现在同一个合法请求中。以下针对两种参数搭配错误的场景逐一说明服务器的标准处理逻辑：

场景1：/authorize请求带response_type=token，同时错误带入grant_type=authorization_code #

授权服务器会直接返回invalid_request错误。原因是grant_type是/token端点的专属参数，/authorize端点不接受该参数，客户端的请求不符合OAuth2.0规范的参数定义，属于无效请求。

如果是另一种情况：客户端先通过/authorize?response_type=token拿到隐式授权的令牌，之后又向/token端点发送grant_type=authorization_code的请求（但未携带合法授权码），服务器会返回invalid_grant错误——因为authorization_code类型的请求必须提供有效的授权码，而隐式流程不会生成授权码，客户端无法满足该要求。

场景2：/authorize请求带response_type=code，同时错误带入grant_type=implicit #

同样，服务器会返回invalid_request错误。grant_type不属于/authorize端点的合法参数列表，客户端的请求违反规范，直接被拒绝。

如果是客户端先通过/authorize?response_type=code拿到授权码，之后向/token端点发送grant_type=implicit的请求，服务器会返回unsupported_grant_type或invalid_grant错误。因为implicit授权流程的设计是直接在/authorize端点返回令牌，完全不需要调用/token端点，客户端用grant_type=implicit请求/token本身就不符合流程定义，服务器会判定为无效请求。

总体来说，合规的OAuth2.0授权服务器会严格校验每个端点的参数合法性，任何违反规范的参数组合都会直接返回对应的错误码，这是保障授权流程安全的基础要求。

内容的提问来源于stack exchange，提问作者Shantanu Srivastava