OAuth 2.0 资源服务器自定义错误格式

Question

OAuth 2.0 specification对Section 5.2. Error Response中授权服务器返回的错误非常清楚：

• 错误：必填。

• error_description：可选
• error_uri：可选

[...]

参数包含在 HTTP 响应的实体正文中 使用 [RFC4627] 定义的“application/json”媒体类型。

甚至提供了一个示例 HTTP 响应：

 HTTP/1.1 400 Bad Request
 Content-Type: application/json;charset=UTF-8
 Cache-Control: no-store
 Pragma: no-cache

 {
   "error":"invalid_request"
 }

说到资源服务器（受保护的 HTTP 资源），RFC 在Section 7.2 中对这部分内容含糊其辞：

如果资源访问请求失败，资源服务器应该通知 错误的客户。
虽然此类错误响应的细节 超出了本规范的范围，本文件建立 Section...中的一个通用注册表

可能已经有其自定义错误响应“数据结构”。 像 spring-security-oauth2 这样的实现，默认情况下授权服务器和资源服务器使用相同的错误格式。

这种默认行为会导致 API 客户端针对授权错误和业务错误处理两种不同的数据结构，非常不便。

另一方面，我发现基于授权框架来塑造 HTTP API 的错误真的很奇怪：尤其是当我们对同一资源使用多种类型的授权/身份验证时。

在这一点上，我发现为所有资源服务器错误（包括与 OAuth 相关的授权错误，如“invalid_token”）使用相同的用户定义错误结构更有吸引力。

前：

{
  "error": {
    "code":"1001"
    "type":"invalid_token"
    "message":"Expired access token"
  }
  ...
}

问题：为资源服务器定义我们自己的错误响应格式是一种“坏”/不常见的做法吗？有什么我可能会忘记考虑的元素吗？

我们的想法是尽可能方便用户。

Answer 1

Client 和 Authorization Server 之间的接口定义良好的原因是互操作性。客户端应该能够（或多或少）使用任意授权服务器。

另一方面，客户端和资源服务器之间的接口定义不太明确。这是因为客户端本质上更紧密地绑定到资源服务器，因为它无论如何都需要了解 API 的特定语义和语法，然后才能使用它做一些有用的事情。语义和语法本身扩展到 API 的错误处理。

但是，如果您同时控制资源服务器和客户端，则从开发人员的角度来看，采用与 OAuth 2.0 相同的方法来使客户端的错误处理更加统一可能是有意义的。这并不少见，当然也不是坏习惯。这完全取决于您（即资源服务器实施者）。

Answer 2

与大多数 Spring Security 身份验证错误一样，此错误由 AuthenticationEntryPoint 处理。默认情况下，您会在OAuth2AuthenticationProcessingFilter 中注入OAuth2AuthenticationEntryPoint，但您可以添加自己的过滤器，方法是自己构建过滤器或将其推送到ResourceServerConfigurer 回调中。