Single Sign-On: единый вход между приложениями

Single Sign-On (SSO) — сценарий, при котором пользователь проходит вход один раз у провайдера идентификации, а затем может открыть несколько связанных приложений без повторного ввода учётных данных. SSO отвечает за удобство повторного входа. Оно не заменяет проверку токенов и не выдаёт приложению права само по себе.

Как работает SSO

У пользователя есть сессия у authorization server. Каждое приложение остаётся отдельным OAuth/OIDC client со своим client_id и Redirect URI.

Приложение A -> Authorization Server: вход
Пользователь -> Authorization Server: аутентификация
Authorization Server -> Приложение A: токены

Приложение B -> Authorization Server: новый authorization request
Authorization Server -> Приложение B: вход уже подтверждён
Authorization Server -> Приложение B: новый code и токены для B

Приложение B не получает токены приложения A. Сервер авторизации использует свою сессию, чтобы не спрашивать пользователя повторно, но выпускает новый результат для конкретного client.

Что SSO решает

SSO полезен, когда один продукт состоит из нескольких приложений:

• основной веб-сервис;
• административная панель;
• отдельный frontend;
• мобильное приложение;
• внутренний портал.

Без SSO каждое приложение может просить пользователя войти отдельно. С SSO вход централизован, а приложения получают стандартный OIDC-результат и создают свои локальные сессии.

Что SSO не решает

SSO не означает, что приложения автоматически доверяют любому запросу пользователя. Каждый client должен:

• проверить свой callback;
• проверить полученный ID Token или Access Token;
• использовать свой client_id;
• самостоятельно определить локальные роли и права;
• не передавать токены между приложениями.

Если пользователю разрешён вход в панель, это не означает автоматически, что он может удалить данные. Аутентификация и авторизация остаются разными задачами.

SSO и Project

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

При этом каждое подключение всё равно имеет собственную конфигурацию. Для каждого приложения нужно зарегистрировать свой Redirect URI и использовать соответствующий client ID. Не объединяйте приложения в один client только ради SSO.

SSO и профили пользователя

Пользователь Authoriza может иметь профиль в проекте. Приложение получает sub из токена и использует его для связи с локальной учётной записью. Внутренние роли и права приложения не становятся общими только потому, что приложения используют SSO.

Если один человек работает в разных Project, не следует считать его sub одинаковым во всех проектах. Модель User, Project и Profile описана в основных концепциях.

SSO и срок действия сессии

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

Поэтому logout нужно проектировать явно:

• локальный logout очищает сессию конкретного приложения;
• provider logout завершает центральную сессию, если такой endpoint и сценарий поддерживаются используемым OIDC-контрактом;
• выход из одного приложения не следует автоматически называть глобальным logout.

Типичные ошибки

Передавать токен между приложениями

Приложение A не должно передавать Access Token приложению B через URL, localStorage или собственный API. B должен выполнить собственный OIDC flow.

Смешивать SSO и общую авторизацию

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

Использовать один Redirect URI для всех clients

Redirect URI относится к конкретному client. Зарегистрируйте отдельный callback для каждого приложения и не обходите проверку wildcard-адресами.

Называть локальный logout глобальным

Если SDK удалил локальную сессию, это ещё не доказывает завершение сессии у provider. Проверяйте фактический OIDC-контракт перед обещанием пользователю полного выхода.

Как проверить результат

• пользователь входит в первое приложение;
• второе приложение запускает собственный authorization request;
• повторного ввода данных нет, если центральная сессия ещё действует;
• второе приложение получает собственный code и свои токены;
• оба приложения проверяют полученные токены;
• роли и доступ к ресурсам проверяются отдельно в каждом приложении;
• локальный logout не описывается как provider logout без подтверждённого сценария.

Как это связано с Authoriza

Authoriza группирует приложения в Project и предоставляет OIDC flow для каждого подключения. Это позволяет строить SSO между связанными приложениями, сохраняя отдельные client ID, Redirect URI, токены и проверки доступа.

Чем Authoriza может быть полезна

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