OAuth 2.0 ресурс сервера пользовательский формат ошибки

Question

OAuth 2.0 specification очень ясно, на ошибках, возвращаемых сервером авторизации в Section 5.2. Error Response:

• ошибка: ТРЕБУЕТСЯ.
• error_description: ДОПОЛНИТЕЛЬНОЕ
• error_uri: ДОПОЛНИТЕЛЬНОЕ

[...]

параметры включены в тело объекта ответа HTTP с помощью «приложения/json ", как определено в [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:

Если запрос доступа к ресурсу выходит из строя, сервер ресурсов ДОЛЖЕН сообщить клиенту ошибки.
Хотя специфика таких ответов ошибок выходит за рамки данной спецификации, этот документ устанавливает общий реестр в разделе ...

Можно уже иметь свою «структуру данных» пользовательских ответ ошибки в месте , Реализации, такие как spring-security-oauth2, используют одинаковый формат ошибок для сервера авторизации и сервера ресурсов по умолчанию.

Это поведение по умолчанию приведет клиентов API к обработке двух разных структур данных для ошибок авторизации и бизнес-ошибок, что очень неудобно.

С другой стороны, мне очень сложно форматировать ошибки HTTP API на основе структуры авторизации: особенно, когда мы используем несколько типов авторизации/аутентификации для тех же ресурсов.

На данный момент я считаю более привлекательным иметь такую ​​же определенную пользователем структуру ошибок для всех ошибок сервера ресурсов, включая ошибки авторизации, связанные с OAuth, такие как «invalid_token».

например:

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

Вопрос: это «плохой»/редкость практика, чтобы определить свой собственный формат ответа ошибки сервера ресурсов? Любые элементы, которые я могу забыть рассмотреть?

Идея должна быть максимально удобной.

Answer 1

Причина, по которой интерфейс между клиентом и сервером авторизации хорошо определен, обусловлен интероперабельностью. Клиенты должны иметь возможность работать с (более или менее) произвольными серверами авторизации.

С другой стороны, интерфейс между Клиентами и серверами ресурсов менее определен. Это связано с тем, что Клиент по своей сути более тесно связан с сервером ресурсов, потому что он должен понимать специфическую семантику API и синтаксис API в любом случае, прежде чем он сможет что-то сделать с этим. Семантика и синтаксис распространяются на обработку ошибок для API.

Но если вы будете управлять как сервером ресурсов, так и клиентом, это может иметь смысл с точки зрения разработчика принять тот же подход, что и для OAuth 2.0, чтобы сделать обработку ошибок более однородной для клиента. Это не редкость и, конечно, неплохая практика. Это действительно зависит от вас (т. Е. Реализатор сервера ресурсов).

Answer 2

Как и в случае большинства ошибок проверки подлинности Spring Security, этот обрабатывается AuthenticationEntryPoint.По умолчанию вы получаете OAuth2AuthenticationEntryPoint, введенный в ваш OAuth2AuthenticationProcessingFilter, но можете добавить свой собственный, либо создав фильтр самостоятельно, либо нажав его в обратном вызове ResourceServerConfigurer.