SSO (Single Sign-On)
SSO (Single Sign-On) — это технология единой аутентификации, при которой пользователь один раз входит в систему и получает доступ ко всем связанным сервисам без повторного ввода логина и пароля.
Что такое SSO простыми словами? Это «мастер-ключ» от всех корпоративных приложений. Single sign on это способ централизованного управления доступом через Identity Provider (IdP).
В статье:
✅ схема работы SSO,
✅ протоколы SAML, OAuth, OpenID Connect,
✅ преимущества и недостатки,
✅ как внедрить SSO в компании,
✅ российские решения,
✅ частые ошибки и безопасность.
📑 Содержание
- Что такое SSO (Single Sign‑On) простыми словами
- Как работает SSO авторизация: полная схема
- Архитектура SSO: место в IAM
- Identity Federation — доверие между системами
- Протоколы SSO: SAML, OAuth, OpenID Connect
- Жизненный цикл SSO-сессии
- Сценарии отказов (Failure Modes) и их решения
- Безопасность SSO: риски и MFA
- SSO в России: тренды и решения
- SSO vs LDAP, OAuth, MFA
- Как внедрить SSO в компании: пошаговая инструкция
- Реальные сценарии использования
- Частые ошибки внедрения
- FAQ: ответы на частые вопросы
Что такое SSO (Single Sign‑On) простыми словами
SSO — это система, где пользователь входит один раз через Identity Provider и получает доступ ко всем приложениям компании.
Пример из жизни: вы входите в корпоративный ноутбук под своей учётной записью — и сразу открываются Outlook, Teams, CRM и Jira. Вам не нужно вводить пароль повторно.
SSO авторизация — что это?
SSO авторизация — это процесс проверки подлинности пользователя через единый Identity Provider (IdP, провайдер идентификации), после чего он получает доступ ко всем подключённым приложениям без повторного ввода логина и пароля. Простыми словами: вы один раз «авторизуетесь» в системе, и она запоминает вас для всех остальных сервисов.
Как работает SSO авторизация: полная схема
SSO авторизация строится на доверии между пользователем, приложением (Service Provider) и Identity Provider. IdP выдаёт криптографически подписанный токен, который принимают все подключённые сервисы.
Пошаговая схема работы SSO
| Этап | Что происходит | Участники |
|---|---|---|
| 1 | Пользователь открывает приложение (например, CRM) | User → SP |
| 2 | SP перенаправляет запрос на Identity Provider | SP → IdP |
| 3 | Пользователь вводит логин/пароль (и MFA, если включено) | User → IdP |
| 4 | IdP проверяет данные и создаёт токен (JWT / SAML Assertion) | IdP |
| 5 | Токен возвращается в приложение через защищённый канал | IdP → SP |
| 6 | Приложение проверяет подпись токена и открывает доступ | SP |
| 7 | При переходе к другому приложению повторный вход не требуется | User → другой SP |
Архитектура SSO: место в IAM
SSO не является самостоятельной системой — это важная часть IAM-архитектуры (Identity and Access Management). Вместе с MFA, RBAC и каталогом пользователей он формирует полный цикл управления идентификацией.
Что такое IAM (Identity and Access Management)?
IAM (управление идентификацией и доступом) — это комплексная система, которая отвечает за:
- Идентификацию — кто есть кто (учётные записи, каталоги).
- Аутентификацию — подтверждение личности (пароли, MFA, SSO).
- Авторизацию — что разрешено (роли, политики доступа).
- Управление жизненным циклом — создание, блокировка, удаление учёток.
Простыми словами: IAM — это система «пропусков и ключей» в цифровом мире компании. SSO — лишь один из её инструментов (инструмент единого входа).
Компоненты IAM: где SSO вписывается в общую картину
| Компонент IAM | Функция |
|---|---|
| SSO | единый вход, выдача токенов |
| MFA | многофакторная защита |
| RBAC | роли и права доступа |
| Policy Engine | правила доступа (условная политика) |
| Directory (AD/LDAP) | хранение учётных записей |
Identity Federation — доверие между системами
Identity Federation — это механизм доверия между разными провайдерами идентификации (Identity Provider). Он позволяет пользователю из одной организации получить доступ к приложениям другой без создания нового аккаунта.
| Сценарий | Результат |
|---|---|
| Компания A использует Keycloak, компания B — Azure AD | Федерация → сотрудники A входят в сервисы B через свои учётные данные |
| Объединённая корпоративная группа | Единая точка входа через федерацию IdP |
| B2B-портал | Партнёры заходят без регистрации нового пароля |
Технически реализуется через: SAML 2.0 metadata, OIDC federation, mutual SSL/TLS.
Протоколы SSO: SAML, OAuth, OpenID Connect
SSO реализуется через три основных протокола: SAML (корпоративный), OAuth 2.0 (доступ к API) и OpenID Connect (аутентификация для веба и мобилок).
Таблица протоколов
| Протокол | Назначение | Формат данных | Типичное использование |
|---|---|---|---|
| SAML 2.0 | Enterprise SSO (аутентификация + авторизация) | XML (Assertion) | Корпоративные веб-приложения, Active Directory, госорганы |
| OAuth 2.0 | Делегирование доступа к API | JSON / Bearer Token | «Войти через Google», доступ к ресурсам без пароля |
| OpenID Connect (OIDC) | Аутентификация поверх OAuth 2.0 | JWT (ID Token) | Современные SPA, мобильные приложения |
Важно: Сам по себе OAuth 2.0 не даёт единого входа (SSO) — он только позволяет приложению получить доступ к API. Настоящий SSO с OAuth обеспечивает только OpenID Connect (OIDC), который добавляет слой аутентификации и ID Token.
OAuth Authorization Code Flow: пользователь → приложение → редирект на сервер авторизации → логин + MFA → авторизационный код → обмен на токен доступа → доступ к API.
Жизненный цикл SSO-сессии
Жизненный цикл SSO управляется Identity Provider и включает этапы от входа до завершения сессии. Корректное управление токенами критически важно для безопасности.
| Этап | Описание |
|---|---|
| Login | Пользователь вводит логин/пароль + MFA |
| Token issuance | IdP выдаёт токен (JWT, SAML Assertion) |
| Active session | Пользователь работает с приложениями |
| Refresh | Обновление токена без повторного входа (refresh token) |
| Revocation | Администратор отзывает доступ или истекает срок |
| Logout | Завершение сессии (Single Logout) |
Сценарии отказов (Failure Modes) и их решения
SSO создаёт единую точку отказа — Identity Provider. При его недоступности пользователи теряют доступ ко всем системам. Ниже — основные проблемы и способы их устранения.
| Проблема | Последствие | Решение |
|---|---|---|
| IdP недоступен (сбой, DDoS) | Падение всех сервисов | Кластеризация, резервный IdP, offline-токены |
| Истёк срок токена (Token expired) | Внезапная потеря доступа | Автоматическое обновление через refresh token |
| Расхождение времени (Clock skew) | Ошибки проверки SAML Assertion | Синхронизация времени (NTP), допуск в 2-5 минут |
| Просрочен сертификат IdP | Сбой подписи токенов | Автоматизация ротации сертификатов |
| MFA недоступна | Блокировка входа пользователей | Fallback MFA (резервный метод или временное отключение с логированием) |
Безопасность SSO: риски и MFA
SSO повышает безопасность при условии обязательного использования MFA и короткого времени жизни токенов. Основные риски — компрометация IdP, фишинг, украденный токен.
🛡 Рекомендации по безопасности
- Обязательная MFA (TOTP, push-уведомления, ключи безопасности) — снижает риск компрометации на 99%.
- Короткое время жизни токенов (не более 8–12 часов для сессии, refresh token — 7 дней).
- Conditional Access — доступ только с доверенных устройств и по геолокации.
- Аудит логинов и ревокаций — централизованные логи IdP.
- Резервный IdP или cached sessions для офлайн-доступа.
SSO в России: тренды и решения
В России набирают популярность self-hosted SSO на базе Keycloak и отечественные платформы (Avanpost, Solar SSO) из-за требований импортозамещения и 152-ФЗ.
| Решение | Тип | Для кого |
|---|---|---|
| Keycloak | Open Source (self-hosted) | Компании с собственной разработкой, импортозамещение |
| Avanpost FAM | Enterprise РФ (on‑premise) | Госорганизации, банки, 152-ФЗ |
| Solar SSO | Platform security | Крупный бизнес, госкомпании |
| Bitrix IAM | SaaS / on‑premise | Компании на Битрикс24, средний бизнес |
| Microsoft Entra ID (Azure AD) | Hybrid | Компании с экосистемой Microsoft |
Тренд: переход от облачных IAM к собственным контурам с сохранением поддержки SAML и OIDC.
Сравнение SSO с LDAP, OAuth и MFA
SSO часто путают с LDAP, OAuth и MFA, но это разные технологии, которые решают разные задачи.
SSO vs LDAP
| SSO | LDAP |
|---|---|
| Единый вход через IdP, токены доступа | Каталог пользователей (хранение), не даёт единого входа |
SSO vs OAuth
| SSO | OAuth |
|---|---|
| Обеспечивает вход в системы (аутентификация) | Даёт приложению доступ к API (авторизация) |
SSO vs MFA
| SSO | MFA |
|---|---|
| Упрощает вход (удобство) | Усиливает безопасность (дополнительный фактор) |
Лучшая практика: SSO + MFA вместе.
Как внедрить SSO в компании: пошаговая инструкция
Внедрение SSO начинается с выбора Identity Provider и подключения ключевых приложений через SAML или OIDC. Ниже — готовый план для IT-команды.
- Выберите IdP (см. таблицу российских и глобальных решений выше).
- Составьте список приложений (CRM, почта, мессенджеры, ERP, файловые хранилища).
- Настройте IdP: добавьте домен, пользователей, группы, включите MFA.
- Для каждого приложения получите SAML-метаданные или OIDC-конфигурацию (Issuer, Redirect URI, Certificate).
- Настройте доверие: в IdP укажите приложение как Service Provider, задайте атрибуты (email, имя, роль).
- Проведите пилот на 5–10 пользователях, проверьте вход и logout.
- Разверните на всю компанию, проведите обучение сотрудников.
- Настройте мониторинг (логи, оповещения о подозрительных входах).
Реальные сценарии использования SSO
SSO используется повсеместно: от офисных экосистем до B2B-порталов и госуслуг.
| Сценарий | Пример |
|---|---|
| Корпоративная экосистема Google | Gmail → Drive → Meet → Calendar |
| Microsoft 365 | Outlook → Teams → SharePoint → OneDrive |
| Российский корпоративный контур | CRM → ERP → HR → BI (единый вход через Keycloak или Avanpost) |
| Госуслуги / ЕСИА | Единый вход во все государственные порталы (на самом деле федерация через ЕСИА) |
| Социальные сети (Social Login) | «Войти через ВКонтакте / Google / Apple» |
Частые ошибки внедрения SSO
Ошибки при настройке SSO могут привести к блокировкам пользователей или дырам в безопасности.
| Ошибка | Последствие | Решение |
|---|---|---|
| Отсутствие MFA | Взлом одного пароля даёт доступ ко всем системам | Включить MFA перед внедрением SSO |
| Нет резервного IdP | При сбое основного — полная остановка работы | Кластеризация, резервный сервер |
| Плохая интеграция с legacy-системами | Ошибки перенаправления, двойной вход | Использовать прокси-аутентификацию или шлюзы |
| Слишком долгое время жизни токена | Риск компрометации сессии | Токены на 8–12 часов, refresh token на 7 дней |
| Отсутствие Single Logout | Выход из одного приложения не завершает сессию в других | Настроить глобальный logout через IdP |
Заключение
SSO (Single Sign-On) — фундаментальная технология IAM, которая обеспечивает единый вход в корпоративные и облачные системы через Identity Provider, используя стандарты SAML, OAuth 2.0 и OpenID Connect. Правильно настроенный SSO с MFA и резервированием IdP повышает безопасность и удобство работы. Начните с выбора IdP, подключите самые критичные приложения и масштабируйте.
FAQ: ответы на частые вопросы о SSO
Что такое SSO простыми словами?
SSO (Single Sign-On) — это единый вход, позволяющий использовать один аккаунт для всех систем компании. Как ключ от всех дверей.
SSO — это безопасно?
Да, при использовании MFA и корректной настройке Identity Provider. Без MFA безопасность снижается.
Чем SSO отличается от OAuth?
OAuth даёт приложению доступ к API без пароля, SSO обеспечивает единый вход в системы (аутентификацию).
Что такое Identity Provider?
Identity Provider — это сервер, который проверяет пользователя и выдаёт токен доступа. Примеры: Azure AD, Keycloak, Okta.
Что такое федерация идентичности?
Это механизм доверия между разными системами авторизации, позволяющий использовать учётные данные одной организации в другой.
Можно ли использовать SSO без интернета?
Да, если используется локальный IdP (например, Keycloak внутри корпоративной сети). Облачным IdP нужен интернет.
Как внедрить SSO в небольшой компании?
Выберите облачный IdP (Google Workspace, Microsoft 365), настройте SAML-приложения, включите MFA. Не требует своей инфраструктуры.
Что такое единая точка отказа в SSO?
Когда Identity Provider становится недоступным, пользователи теряют доступ ко всем системам сразу. Решается резервированием IdP.
Какие протоколы используются в SSO?
Основные: SAML 2.0 (корпоративный), OAuth 2.0 (API), OpenID Connect (современные приложения).
Сколько стоит внедрение SSO?
Open Source-решения (Keycloak) бесплатны, но требуют собственных серверов и специалистов. Облачные российские сервисы (Avanpost FAM, Solar SSO) и зарубежные (Okta, Microsoft Entra ID) стоят от 200 до 600 ₽ за пользователя в месяц в зависимости от функционала. Для малого бизнеса часто достаточно встроенного SSO в Google Workspace или Microsoft 365 — он включён в базовые тарифы.