Single Sign-On (SSO) — протокол федеративной идентификации, позволяющий одной операции аутентификации давать доступ к множеству приложений и сервисов. Пользователь проходит проверку в центральном провайдере идентификации (Identity Provider, IdP), который выдаёт токен доверия; все остальные приложения (Service Provider, SP) принимают этот токен без запроса повторных учётных данных.
Как работает SSO
Когда пользователь открывает защищённое приложение, SP перенаправляет браузер на IdP. IdP проверяет сессию: если сессия активна — возвращает токен авторизации обратно в SP; если нет — запрашивает логин и пароль. После проверки IdP создаёт криптографически подписанное утверждение (assertion) и передаёт его SP. SP проверяет подпись по публичному ключу IdP и открывает доступ.
Для передачи утверждений используются два основных стандарта. SAML 2.0 (Security Assertion Markup Language, RFC 3852) работает через XML-документы и применяется в корпоративных средах с 2005 года. OpenID Connect (OIDC) — современный слой поверх OAuth 2.0, работает через JWT-токены и используется в веб- и мобильных приложениях. Kerberos — третий вариант, работает в доменных сетях Windows через билеты TGT (Ticket Granting Ticket) и применяется с 1988 года.
Время жизни сессии IdP задаётся параметром SessionNotOnOrAfter в SAML или exp-claim в JWT. Типичное значение — 8 часов рабочего дня. По истечении пользователь проходит повторную аутентификацию.
Архитектурные компоненты
- Identity Provider (IdP) — Okta, Azure AD, Keycloak, Google Workspace. Хранит учётные данные и выдаёт assertion.
- Service Provider (SP) — приложения, доверяющие IdP: Jira, Slack, GitHub Enterprise, панели управления хостингом.
- Directory — LDAP или Active Directory, с которым синхронизируется IdP.
- Token store — Redis или база данных для хранения активных сессий.
История
Первые реализации SSO появились в 1988 году с выходом Kerberos v4 в MIT. В 2001 году консорциум OASIS опубликовал черновик SAML 1.0; финальная версия SAML 2.0 вышла в 2005 году и стала основой корпоративного SSO на следующее десятилетие. В 2012 году IETF утвердил OAuth 2.0 (RFC 6749), а в 2014 году OpenID Connect 1.0 добавил слой идентификации поверх OAuth, перенеся SSO в облачную и мобильную экосистемы. Сегодня крупнейшие IdP-провайдеры — Okta (IPO 2017), Azure Active Directory (переименован в Microsoft Entra ID в 2023), Ping Identity.
SSO в контексте хостинга и серверов
Для хостинг-провайдеров SSO критично при управлении несколькими панелями: ISPmanager, cPanel, VMware vSphere и внутренние системы мониторинга интегрируются через единый IdP. Это устраняет проблему «password fatigue» — когда сотрудник управляет 10+ паролями для разных систем — и упрощает revocation: достаточно деактивировать аккаунт в IdP, чтобы заблокировать доступ ко всем сервисам одновременно.
Многофакторная аутентификация (MFA) совместима с SSO и применяется на уровне IdP: пользователь проходит MFA один раз при входе в IdP, а не при каждом переходе между сервисами. Это сочетает безопасность с удобством.
Риски и ограничения
Единая точка аутентификации становится единой точкой отказа. Если IdP недоступен — недоступны все привязанные сервисы. Для production-сред IdP разворачивают в HA-конфигурации (2+ нод) с failover. Компрометация учётной записи в IdP открывает доступ ко всем SP одновременно, поэтому MFA обязательна. Для SSO с SAML требуется синхронизация времени (NTP) между IdP и SP с точностью до ±5 секунд — иначе assertion будет отклонён как просроченный.