Question

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

错误：必须。

error_description ：可选

error_uri ：可选


[...]

参数包含在HTTP响应的实体主体中      使用＆＃34; application / json＆＃34;媒体类型，由[RFC4627]定义。

甚至提供了一个示例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中对此部分含糊不清：

如果资源访问请求失败，资源服务器应该通知     错误的客户。
    而这种错误反应的具体细节     超出本规范的范围，本文件确立     章节中的共同注册表...

可能已经有了自定义错误响应＆＃34;数据结构＆＃34;到位。 spring-security-oauth2等实现默认使用与授权服务器和资源服务器相同的错误格式。

此默认行为将导致API客户端处理两个不同的数据结构，以解决授权错误和业务错误，这非常不方便。

另一方面，我发现根据授权框架模拟HTTP API的错误真的很奇怪：特别是当我们对同一资源使用多种类型的授权/身份验证时。

此时我发现为所有资源服务器错误提供相同的用户定义错误结构更具吸引力，包括OAuth相关的授权错误，例如＆＃34; invalid_token＆＃34;。

前：

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

问题： 为资源服务器定义我们自己的错误响应格式是不是很糟糕＆＃34; /不常见的做法？我可能忘记考虑的任何因素？

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

Answer 1

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

Answer 2

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

另一方面，客户端和资源服务器之间的接口定义不太明确。这是因为客户端本质上更紧密地绑定到资源服务器，因为它需要先了解API的API特定语义和语法，然后才能对它执行一些有用的操作。语义和语法扩展到API的错误处理。

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

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

2 个答案: