如何响应因response_type无效而失败的OAuth 2.0授权端点请求？

Question

来自RFC 6749 section 4.2.2.1：

  

如果资源所有者拒绝访问请求或者请求因缺少或无效的重定向URI以外的原因而失败，则授权服务器通过将以下参数添加到片段组件来通知客户端重定向URI

来自RFC 6749 section 4.1.2.1：

  

如果资源所有者拒绝访问请求，或者请求因缺少或无效的重定向URI以外的原因而失败，则授权服务器通过将以下参数添加到查询组件来通知客户端重定向URI

前者适用于授权端点的隐式授权流请求;后者适用于授权端点的授权代码流请求。差异由客户端发送到授权端点的response_type参数指示; token表示隐式流，code表示授权代码流。因此，如果发生错误，则逻辑如下：

if response_type == 'token'
  error response in fragment
else if response_type == 'code'
  error response in query string
else
  ????????????????????
end

规范似乎让它在最后的“其他”中做了什么。可能的客户端错误是包含response_type参数，其值不是code或token。这可能不符合不可重定向错误的标准，因此如果可能，授权服务器应重定向到redirect_uri并使用适当的错误响应（error=invalid_request或可能error=unsupported_response_type）。

但是这个错误参数在哪里？查询组件或片段？都？毕竟这应该被视为无法重定向的错误，如无效的redirect_uri？

Answer 1

仔细阅读RFC 6749，可以发现客户端可以访问授权端点，而无需在某些条件满足时提前注册其重定向URI。条件是（1）机密，（2）隐式和（3）显式redirect_uri参数。在这种情况下，需要在确定redirect_uri之前确定response_type。这意味着存在无法通过重定向向客户端报告unsupported_response_type错误的情况。因此，我们不必总是通过重定向报告unsupported_response_type错误（因为在这种情况下我们无法执行此操作）。

如果我是你，我会发送＆＃34; 400 Bad Request＆＃34;给客户端带错误消息。恕我直言，无法正确指定response_type的客户端无法通过重定向接收响应，并且应该在早期开发阶段之前通知此类基本错误。