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

Question

来自RFC 6749 section 4.2.2.1：

如果资源所有者拒绝访问请求，或者请求因重定向 URI 丢失或无效以外的原因而失败，授权服务器会通过在 fragment 组件中添加以下参数来通知客户端重定向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 错误（因为在这种情况下我们不能这样做）。

如果我是你，我只会向客户端发送“400 Bad Request”和错误消息。恕我直言，甚至无法正确指定 response_type 的客户端没有资格通过重定向接收响应，并且应该在早期开发阶段尽早通知此类基本错误。