Когда API выполняет аутентификацию токена HTTP с помощью Introspection, что он должен вернуть, если сервер Introspection выключен или возвращает 500?

Question

Когда API выполняет аутентификацию токена HTTP с помощью Introspection, что он должен вернуть, если сервер Introspection не работает или возвращает 500?

Я пишу API и хочу придерживаться стандартов Http. Если API не удается проверить токен (из-за того, что пользовательский сервер самоанализа не работает или возвращает 500), должен ли API вернуть 401, 422 или 500?

Кроме того, если эта конечная точка самоанализа токена не являетсяконечная точка Oauth должна вернуть тот же Http-код?

Я провел некоторое исследование и обнаружил:

1. https://tools.ietf.org/id/draft-ietf-oauth-v2-bearer-11.xml#authn-header Это говорит: «Если защищенныйзапрос ресурса включал токен доступа и неудачная аутентификация , сервер ресурсов ДОЛЖЕН включать атрибут error, чтобы предоставить клиенту причину отклонения запроса на доступ. Значение параметра описано в разделе 3.1. Кроме того,сервер ресурсов МОЖЕТ включать атрибут error_description, чтобы предоставить разработчикам понятное человеку объяснение, которое не предназначено для отображения конечным пользователям. "

2. https://tools.ietf.org/id/draft-ietf-oauth-v2-bearer-11.xml#resource-error-codes

В нем говорится: «Предоставленный маркер доступа истек, отозван, неправильно сформирован или недействителен по другим причинам . РесурсДОЛЖЕН ответить кодом состояния HTTP 401 (неавторизованным). "

Теперь вышесказанное заставляет меня думать, что при использовании Oauth Introspection наверняка 401 - правильный подход в данном случае, а не 500. поскольку аутентификация не была успешной = неудача. Это звучит правильно? Кроме того, должно ли это быть так же и для не-Oauth Introspection?

Я рассмотрел код Microsoft для их пакета Introspection API ядра .net. Это показывает, что они возвращают 401 в этом случае. Код по адресу: https://github.com/aspnet-contrib/AspNet.Security.OAuth.Extensions/blob/dev/src/AspNet.Security.OAuth.Introspection/OAuthIntrospectionHandler.cs

Соответствующая часть:

// Return a failed authentication result if the introspection
// request failed or if the "active" claim was false.
var payload = await GetIntrospectionPayloadAsync(token);
if (payload == null || !payload.Value<bool>(OAuthIntrospectionConstants.Claims.Active))
{
    Context.Features.Set(new OAuthIntrospectionFeature
    {
        Error = new OAuthIntrospectionError
        {
            Error = OAuthIntrospectionConstants.Errors.InvalidToken,
            ErrorDescription = "The access token is not valid."
        }
    });

    return AuthenticateResult.Fail("Authentication failed because the authorization " +
                                    "server rejected the access token.");
}

Наконец-то я наткнулся на это: https://tools.ietf.org/html/rfc6750#section-2.1

Что говорит: «Если защищенныйзапрос ресурса не включает учетные данные аутентификации или не содержит токен доступа, который разрешает доступ к защищенному ресурсу , сервер ресурсов ДОЛЖЕН включать поле заголовка ответа HTTP «WWW-Authenticate», он МОЖЕТ включать его в ответк другим условиям. "

Answer 1

Вам определенно не нужна ошибка 4xx, поскольку она предполагает, что она может быть решена клиентом или, по крайней мере, ошибкой на стороне клиента. Это явный сбой, поэтому ваш код ошибки должен начинаться хотя бы с 5.

. Если вы обращаетесь к внешней службе, эта служба не работает или работает неправильно, и эта служба критична (например, вы ничего не можете сделать вусловия резервирования) наиболее подходящий код состояния может быть 503 Service Unavailable.