Управление сессиями OIDC

Что такое управление сессиями OIDC#

OpenID Connect (OIDC) — это простая идентификационная надстройка, построенная на основе протокола OAuth 2.0. Она позволяет клиентам проверять личность конечного пользователя на основе аутентификации, выполненной сервером авторизации, а также получать основную информацию о профиле конечного пользователя в совместимом стиле, похожем на REST.

OIDC разработан с акцентом на простоту и гибкость и широко используется для единого входа (SSO) и верификации личности в веб-приложениях, мобильных приложениях и API.

Понимание состояния аутентификации и управления сессиями в OIDC крайне важно. Эта статья объясняет, как сессии OIDC и состояние аутентификации пользователей управляются в контексте взаимодействий между провайдером идентификации (IdP) и доверяющейся стороной (RP) или провайдером услуг (SP).

Эта статья включает несколько ключевых терминов.

• Провайдер идентификации (IdP): Служба, которая хранит и аутентифицирует идентичности пользователей.
• Провайдер услуг (SP) или доверяющаяся сторона (RP): Веб-приложение или сервис, который предоставляет услуги пользователям и полагается на IdP для аутентификации пользователей.
• Сессия входа или Сессия аутентификации: Сессия, которая устанавливается, когда пользователь входит в систему IdP.
• Грант: Централизованная информация о аутентификации и авторизации пользователей, которая генерируется и управляется IdP.
• Единый вход (SSO): Служба сессии и аутентификации пользователей, которая позволяет пользователю использовать один набор учетных данных для входа (например, имя и пароль) для доступа к нескольким приложениям.

Как работает поток аутентификации OIDC#

Чтобы лучше понять управление сессиями OIDC и состоянием аутентификации пользователей, давайте кратко рассмотрим поток аутентификации OIDC для веб-приложения:

1. Пользователь получает доступ к веб-приложению (RP).
2. RP перенаправляет пользователя к провайдеру OIDC (IdP) для аутентификации.
3. Провайдер OIDC проверяет статус сессии входа пользователя. Если сессии нет или она истекла, пользователю предлагается войти в систему.
4. Пользователь взаимодействует с страницей входа, чтобы быть аутентифицированным.
5. Страница входа отправляет результат взаимодействия провайдеру OIDC.
6. Провайдер OIDC создает новую сессию входа и грант аутентификации для пользователя.
7. Провайдер OIDC перенаправляет пользователя обратно в RP с кодом аутентификации (Authorization Code flow).
8. RP получает код аутентификации и обменивает его на токены для доступа к информации о пользователе.

Что такое управление сессиями входа RP#

Сессия входа устанавливается, когда пользователь входит в систему IdP. Эта сессия используется для отслеживания состояния аутентификации пользователя в IdP. Сессия обычно включает информацию, такую как личность пользователя, время аутентификации и время истечения сессии. Она создается, когда пользователь впервые входит в систему и поддерживается до тех пор, пока пользователь не выйдет из системы или сессия не истечет.

Файлы cookie сессии будут безопасно установлены в браузере пользователя для поддержания состояния сессии. Файлы cookie сессии используются для идентификации сессии пользователя и аутентификации пользователя для последующих запросов на аутентификацию. Эти файлы cookie обычно устанавливаются с флагами HttpOnly и Secure, чтобы предотвратить доступ с клиентской стороны и обеспечить безопасную связь.

Одна сессия для одного RP#

Для каждого RP, доступного пользователем с разных устройств или браузеров, будет установлена отдельная сессия входа пользователя. Это означает, что статус аутентификации пользователя поддерживается отдельно для каждого RP. Если пользователь выйдет из системы одного RP, он всё равно будет аутентифицирован в других RP до тех пор, пока сессия не истечет или пользователь не выйдет из системы из всех RP.

Централизованная сессия для нескольких RP#

Это централизованное управление сессиями также позволяет IdP поддерживать единое состояние аутентификации через несколько RP, пока сессия пользователя активна и запросы на аутентификацию поступают от одного и того же агента пользователя (устройство/браузер). Этот механизм позволяет использовать возможности SSO, при которых пользователь может получить доступ к нескольким RP без повторного входа в систему.

Статус аутентификации на стороне клиента#

В OIDC клиентское приложение (RP) полагается на токены, выданные IdP, для проверки личности пользователя и статуса аутентификации или авторизации. "Сессия входа" на стороне клиента поддерживается с помощью токенов, выданных IdP.

• ID Token: Краткоживущий токен, который содержит информацию о пользователе и используется для проверки личности аутентифицированного пользователя.
• Access Token: Токен, который предоставляет доступ к защищенным ресурсам от имени пользователя. Срок действия access token может быть краткосрочным или долгосрочным в зависимости от конфигурации. Клиентские приложения могут полагаться на действительность access token, чтобы определить статус аутентификации пользователя. Если access token истек или удалён, пользователь может считаться "вышедшим из системы" или "неаутентифицированным" и должен пройти повторную аутентификацию.
• Refresh Token: Если запрошена и предоставлена область offline_access, клиентское приложение может получить refresh token. Он предоставляет средство для продления статуса аутентификации пользователя, не требуя повторной аутентификации пользователя. Клиентское приложение может использовать refresh token для получения нового access token после истечения срока действия текущего access token. Пока refresh token действителен, статус аутентификации пользователя может поддерживаться без необходимости взаимодействия с пользователем.

Комбинация этих токенов позволяет клиентскому приложению поддерживать статус аутентификации пользователя и получать доступ к защищенным ресурсам от имени пользователя. Клиентское приложение должно надёжно хранить эти токены и управлять их жизненным циклом. (Например, для SPA приложений токены могут быть сохранены в локальном хранилище или хранилище сессий браузера. Для веб-приложений токены могут быть сохранены в данных сессии на стороне сервера или cookie.)

Механизмы выхода из системы в OIDC#

Процесс выхода из системы в OIDC — это многогранная концепция, из-за вовлечения как централизованно управляемых IdP сессий входа, так и распределенных токенов на стороне клиента.

Очистка токенов и локальной сессии на стороне клиента#

Выход из системы или отзыв статуса аутентификации пользователя на стороне клиента относительно прост. Клиентское приложение может удалить сохраненные токены (ID token, access token и refresh token) из браузера пользователя или из памяти. Эта операция фактически аннулирует статус аутентификации пользователя на стороне клиента.

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

Очистка централизованной сессии входа на уровне IdP#

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

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

OIDC back-channel logout#

В некоторых случаях, когда пользователь выходит из одного приложения (RP), он также может захотеть автоматически выйти из всех других приложений (RP) без какого-либо дополнительного взаимодействия с пользователем. Это может быть выполнено с помощью механизма back-channel logout.

Когда IdP получает запрос на выход из системы от RP, он не только очищает сессию входа, но также отправляет уведомление о выходе через back-channel ко всем RP, которые используют ту же сессию и имеют зарегистрированную конечную точку для выхода через back-channel.

Когда RP получают уведомление о выходе через back-channel, они могут предпринять необходимые действия для очистки сессии и токенов пользователя, обеспечивая, что пользователь полностью вышел из всех приложений.