Реализация выхода из системы и управления сессиями в 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).
8. RP получает код аутентификации и обменивается им на токены для доступа к информации о пользователе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OIDC выход через обратный канал#

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

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

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