Что должен содержать WWW-Authenticate по истечении срока сеанса в настройке OpenID Connect?

Сценарий:

app.com делегировал аутентификацию openid-connect.provider.com, то есть неаутентифицированные пользователи перенаправляются внешнему провайдеру для входа в систему, если у них нет действующего сеанса. Как только это произойдет, они получат cookie сеанса app.com некоторой продолжительности.

Хотя с пользовательским потоком все в порядке, мне было интересно, что делать с запросами API? В спецификации сказано, что если вы вернете HTTP 401 UNAUTHORIZED, он должен сопровождаться заголовком WWW-Authenticate, который представляет схему аутентификации для клиента.

Так что же app.com должно возвращать в случае ошибки 401?

Я вижу кусочки, указывающие на OAuth, но я предполагаю, что это относится к внешнему провайдеру входа в систему, а не к самому приложению ( app.com)?

Пример:

 HTTP/1.1 401 Unauthorized
 WWW-Authenticate: Bearer realm="example",
                   error="invalid_token",
                   error_description="The access token expired"

Вышеупомянутое не кажется правильным, поскольку сервер app.com не предъявляет иски к каким-либо токенам доступа в смысле oauth, а только к обычному cookie сеанса для локального сеанса.


http openid-connect openid http-authentication
person oligofren    schedule 27.08.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Перенаправление на вход OIDC по истечении срока действия cookie сеанса - это практика, широко используемая приложениями с интерфейсом пользователя. Что касается файла cookie, используемого здесь, я считаю, что он коррелирует с токеном доступа, полученным потоком OIDC (например: - время жизни cookie, соответствующее времени жизни токена доступа).

Что касается доступа к API, я считаю, что упомянутый API использует использование токена носителя, как определено в RFC6750. Этот RFC определяет, как использовать токен в последующих защищенных вызовах API. Одной из важных его частей является Поле заголовка ответа WWW-аутентификации, который определяет, что делать, если токен недействителен или срок его действия истек. Ответ, который вы нашли, и пример, который вы упомянули в вопросе, соответствуют объяснению рекомендаций RFC.

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

Но если есть настраиваемый механизм аутентификации (например, - cookie), то он выходит за рамки спецификации. Но вы можете получить ответ в формате JSON от API с подробной информацией об ошибке (например: - Http-код, причина, описание и идентификатор корреляции для отладки). Я бы сказал, что заголовок WWW-Authenticate в такой ситуации необязателен.

person Kavindu Dodanduwa    schedule 28.08.2019