Блог

Есть ли в ORY Hydra в настоящее время функция, которая проверяет, вошел ли клиент в систему через OpenID Connect? Я заметил, что есть API для выхода из системы через front-channel

Однако, когда пользователь повторно обращается к поставщику удостоверений, я не могу узнать, вошли ли они в систему в данный момент или нет. Они могут удалить свои HTTP-файлы cookie на стороне клиента, и тогда я не синхронизирован с Hydra. Значение: в Hydra они вошли в систему, но теперь они у меня как вышедшие из системы. Кроме того, в случае выхода из системы по обратному каналу я хочу иметь возможность запрашивать это состояние.

Есть ли API, который я пропускаю, который позволяет мне узнать, есть ли у клиента в настоящее время активный логин OpenID Connect через Hydra?

Похоже, что на данный момент единственное, что можно сделать, это перенаправить пользователя на конечную точку авторизации, поскольку у нас нет возможности узнать, авторизованы они или нет.

Следующие две таблицы, поставляемые с Hydra, по-видимому, являются источником истины для данных, которые мне нужны: hydra_oauth2_access и hydra_oauth2_authentication_session . Имеет ли смысл когда-либо запрашивать их напрямую, если нет поддерживаемого HTTP API из коробки, чтобы узнать, есть ли у пользователя активный сеанс аутентификации?

Отправка запроса на аутентификацию через перенаправление Поставщику prompt=none , включая этот вариант использования: он автоматически войдет в систему и вернет новые токены, если у поставщика есть текущий сеанс единого входа, в противном случае он вернет код ошибки login_required .

Обратите внимание, что в обоих случаях никогда не будет явного взаимодействия с пользователем, поэтому это удобно (и предназначено) для запуска в скрытом iframe.

СОСТОЯНИЕ ВХОДА В СИСТЕМУ

Клиент OAuth чаще всего представляет собой приложение пользовательского интерфейса с несколькими пользователями. Состояние каждого пользователя, вошедшего в систему, представлено файлом cookie сеанса сервера авторизации, к которому ни приложение, ни пользователь не имеют доступа:

• Сервер авторизации (AS) выдает файл cookie единого входа, который будет сохранен в системном браузере для домена AS
• Как веб-интерфейсы, так и собственные пользовательские интерфейсы отправляют его неявно при последующих запросах, когда они вызывают системный браузер

ПЕРЕНАПРАВЛЕНИЕ АВТОРИЗАЦИИ

Когда пользовательский интерфейс OAuth перенаправляет пользователя, обычно неизвестно, является ли:

• Пользователю будет предложено войти в систему
• Пользователь войдет в систему автоматически (например, пользователь мог войти в другое приложение)

Для веб-интерфейса можно отправить перенаправление авторизации в скрытом iframe с параметром prompt =none . Если пользователю необходимо выполнить вход, будет возвращен код ошибки login_required. Для получения дополнительной информации см. Мою страницу обновления токена с молчанием.

Однако это не совсем надежно, и в 2020 году возникнут некоторые проблемы с браузером. Также это может оказаться неподходящим, если вы используете другой тип клиента.

ФЕДЕРАТИВНЫЕ ЛОГИНЫ

В некоторых настройках AS перенаправляет дальше поставщику удостоверений (IDP), а состояние входа пользователя в систему дополнительно зависит от cookie сеанса IDP.

Приложение не может получить доступ к состоянию входа пользователя IDP, поскольку приложение взаимодействует только с AS.

ЕСТЬ ЛИ ПРОБЛЕМА С УДОБСТВОМ ИСПОЛЬЗОВАНИЯ?

Если да, отправьте ответ, и мы сможем обсудить дальше…