OpenID Connect - как обрабатывать одиночный выход

Я изучаю использование OpenID-соединения в качестве протокола SSO для наших корпоративных приложений (ориентированных на потребителя). В общем, большинство аспектов этого согласуются с нашими потребностями, за исключением его способности обрабатывать одиночный выход из системы, и я надеюсь на некоторые рекомендации по этому поводу.

Как отметил человек из ping, одиночный выход из системы отличается от SAML2 тем, что он больше ориентирован на пользователя. Это все хорошо, но он по-прежнему не похож на потребности в реальном одиночном выходе из системы. В частности, ориентированная на пользователя обработка (с помощью некоторой kludgy iframe-связи) работает только для текущего представления браузера, но не будет применяться к RP, который в настоящее время не просматривается. (например, пользователь регистрируется в RPs A, B, C, используя специальный OP. Единственный выход из системы может вызвать только выход из системы для тех RP, которые просматривает браузер). Это оставило бы эти другие сессии затяжными, что может быть проблемой безопасности. (пожалуйста, исправьте, если я неправильно проанализировал это).

Я видел некоторые решения, которые работают вне протокола (например, родительский домен cookie или, возможно, (??) тот же магазин сеансов), но те, к сожалению, не соответствуют моим потребностям.

Я пытаюсь проверить, не пропустил ли я что-то о спецификации OIDC, которая предлагает один протокол выхода, охватывающий случаи использования, подобные собственному одиночному выходу SAML2? (может быть, некоторая прямая связь OP- > RP или даже с выходом "итерации через RP" на стороне клиента?). Или я действительно остался один, чтобы разработать для этого собственное решение?

Кстати, также было бы любопытно, обсуждалось ли это в комитете OIDC (уверен, что оно есть), и следует ли его рассматривать в дорожной карте.

Ответы

Ответ 1

Какое решение вы ожидаете?

SLO будет работать нормально, если вы используете OIDC для защиты ваших ресурсов (вы все равно проверите access_token на доступе к ресурсам, который будет отменен), но не в том случае, если OIDC используется как поставщик удостоверений.

OIDC не имеет push-SLO. Вы не можете реализовать надежную SLO в OP с помощью OIDC.

В настоящий момент каждый RP должен позаботиться о SLO, который указан в упомянутой вами спецификации управления сеансом OIDC. Если RP не находятся под вашим контролем, у вас нет средств для его принудительного применения.

Ответ 2

Официального решения для этого нет, и как Вилмантас правильно указал в своем ответе:

Если RP не находятся под вашим контролем, у вас нет средств для его принудительного применения.

Во всяком случае, все еще есть опция, хотя это может противоречить использованию OpenID Connect, но в любом случае здесь мы идем:

Используйте список аннулирования токена.

Когда пользователь подписывается, поместите токен в список аннулирования у поставщика удостоверений. Затем вам нужен механизм, чтобы нажимать (или регулярно вытягивать) этот список аннулирования на все бэкэнды, полагающиеся на partys. Затем, когда пользователь пытается получить доступ к полагающейся стороне (и у них все еще есть свой токен), хотя токен в основном по-прежнему действителен, полагающаяся сторона может отклонить его, потому что он был отозван тем временем.

Конечно, это означает, что вам нужно какое-то идеальное обновление в реальном времени для списков аннулирования, и это может сделать всю идею OpenID Connect бесполезной. Но это вариант...