Single Sign-On

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

История

Идея единого входа возникла в 1960-х годах в рамках проектов по созданию операционных систем с разделением времени (например, CTSS и Multics). Первые реализации SSO были закрытыми и использовались в крупных корпоративных сетях, где требовалось централизованное управление доступом к мейнфреймам и терминалам.

В 1990-х годах с ростом числа веб-приложений и корпоративных порталов потребность в SSO стала массовой. Корпорация Microsoft внедрила Active Directory (1999) с поддержкой Kerberos — протокола, который стал основой для многих SSO-решений в среде Windows. В 2000-х годах появились открытые протоколы SAML (Security Assertion Markup Language) и OAuth, которые позволили реализовать единый вход в веб-среде, включая федеративные системы (например, eduGAIN для академических учреждений).

С 2010-х годов SSO активно используется в облачных сервисах (Google, Microsoft 365, Salesforce) и социальных сетях (Facebook, «ВКонтакте»). В 2020-х годах стандартом де-факто для веб-приложений стал протокол OpenID Connect (OIDC), построенный на основе OAuth 2.0.

Принцип работы

SSO основан на модели «треугольника доверия»: пользователь, провайдер идентификации (IdP) и сервис-провайдер (SP). Процесс включает следующие этапы:

1. Пользователь заходит в приложение (SP), которое не имеет собственных данных для аутентификации.
2. SP перенаправляет запрос на IdP (например, на страницу входа). Пользователь вводит свои учётные данные.
3. IdP проверяет данные и создаёт токен аутентификации (например, SAML-утверждение или JWT-токен).
4. IdP передаёт токен обратно в SP (через браузер пользователя или напрямую по защищённому каналу).
5. SP проверяет токен (с помощью цифровой подписи IdP) и предоставляет доступ.
6. При последующих обращениях к другим SP, если сессия на IdP активна, пользователь не вводит пароль — IdP автоматически выдаёт токены для новых сервисов.

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

Протоколы и стандарты

SAML (Security Assertion Markup Language)

Разработан OASIS в 2002 году. Основан на XML. Передаёт утверждения (assertions) о пользователе между IdP и SP. Используется в корпоративных средах (например, для интеграции с Active Directory Federation Services). Версия SAML 2.0 (2005) остаётся широко распространённой.

OAuth 2.0

Открытый протокол авторизации (2012). Позволяет делегировать доступ к ресурсам без передачи пароля. Часто используется как основа для SSO через сторонние сервисы (например, «Войти через Google»). Не является протоколом аутентификации сам по себе, но дополняется OpenID Connect.

OpenID Connect (OIDC)

Надстройка над OAuth 2.0 (2014). Добавляет стандартизированный способ получения информации о пользователе (ID-токен в формате JWT). Поддерживается большинством современных облачных платформ (Google, Microsoft, Okta, Keycloak).

Kerberos

Протокол сетевой аутентификации (разработан в MIT, 1980-е). Использует билеты (tickets) и центр распределения ключей (KDC). Широко применяется в доменных сетях Windows (Active Directory) и Unix-системах (через Heimdal или MIT Kerberos).

LDAP (Lightweight Directory Access Protocol)

Протокол для доступа к службам каталогов (например, OpenLDAP, Active Directory). Часто используется как источник данных о пользователях для SSO-систем, но сам по себе не реализует единый вход.

Типы реализации

Корпоративное SSO (Enterprise SSO)

Развёртывается внутри организации. Обычно использует Kerberos, SAML или LDAP. Позволяет сотрудникам входить во все корпоративные приложения (ERP, CRM, почта, файловые серверы) с одним паролем. Примеры: Microsoft Active Directory Federation Services (ADFS), FreeIPA, Keycloak.

Федеративное SSO (Federated SSO)

Объединяет несколько организаций (доменов доверия). Пользователь одной организации может получить доступ к ресурсам другой без создания отдельной учётной записи. Применяется в образовательных (eduGAIN), государственных (GovPass) и межкорпоративных системах. Основа — протоколы SAML и OIDC.

Социальное SSO (Social Login)

Использует учётные записи из социальных сетей или крупных интернет-сервисов (Google, Apple, «ВКонтакте», Яндекс). Реализуется через OAuth 2.0 / OIDC. Упрощает регистрацию на сторонних сайтах, но может вызывать опасения по поводу приватности.

SSO на основе мобильных устройств

Использует биометрию (отпечаток пальца, Face ID) или push-уведомления для аутентификации. Примеры: Apple SSO (Sign in with Apple), Google Smart Lock.

Преимущества

• Удобство для пользователя: не нужно запоминать множество паролей.
• Снижение нагрузки на службу поддержки: меньше запросов на сброс паролей.
• Централизованное управление доступом: администратор может блокировать учётную запись во всех системах сразу.
• Повышение безопасности: возможность внедрения многофакторной аутентификации (MFA) на уровне IdP.
• Снижение риска фишинга: пользователь реже вводит пароль на незнакомых сайтах.

Недостатки и риски

• Единая точка отказа: если IdP недоступен, пользователь теряет доступ ко всем связанным системам.
• Компрометация IdP: злоумышленник, получивший доступ к IdP, может аутентифицироваться от имени любого пользователя во всех сервисах.
• Сложность внедрения: требует настройки доверительных отношений между IdP и SP, синхронизации каталогов, управления сертификатами.
• Проблемы совместимости: не все приложения поддерживают протоколы SSO (особенно устаревшие или самописные).
• Уязвимости в реализации: например, атаки типа «человек посередине» при передаче токенов, подделка SAML-утверждений (если не используется подпись).

Применение

SSO широко используется в:

• Корпоративных информационных системах (SAP, Oracle, 1С:Предприятие) — через ADFS, Keycloak, Azure AD.
• Облачных сервисах (Google Workspace, Microsoft 365, Salesforce) — для входа сотрудников и клиентов.
• Образовательных платформах (Moodle, Blackboard) — через федеративные сети (eduGAIN).
• Государственных порталах (например, «Госуслуги» в России, Gov.uk в Великобритании) — для доступа к электронным услугам.
• Веб-сайтах и мобильных приложениях — через социальное SSO (кнопки «Войти через Google», «ВКонтакте»).

Примеры популярных решений

• Microsoft Entra ID (ранее Azure Active Directory) — облачный IdP, поддерживает SAML, OIDC, Kerberos.
• Okta — облачная платформа SSO для корпоративных приложений.
• Keycloak — открытое решение с поддержкой SAML, OIDC, LDAP, социального входа.
• Auth0 — облачный сервис аутентификации с гибкими настройками.
• FreeIPA — интегрированное решение для Linux-сред (LDAP + Kerberos + DNS).
• Яндекс ID — российский сервис единого входа для сервисов Яндекса и сторонних сайтов (через OAuth 2.0).

Безопасность

Для защиты SSO-систем применяются:

• Многофакторная аутентификация (MFA) — обязательный второй фактор (TOTP, SMS, биометрия) при входе в IdP.
• Цифровые подписи токенов — для предотвращения подделки (SAML-утверждения подписываются закрытым ключом IdP).
• Короткое время жизни токенов — снижает риск при перехвате.
• Проверка реферера и CORS — для защиты от CSRF-атак.
• Аудит и логирование — для обнаружения аномальной активности.

Источники

• RFC 6749 — The OAuth 2.0 Authorization Framework (2012).
• OpenID Connect Core 1.0 — OpenID Foundation (2014).
• SAML V2.0 — OASIS Standard (2005).
• Kerberos: The Definitive Guide — Jason Garman (O'Reilly Media, 2003).
• Active Directory Federation Services — Microsoft Docs (2023).
• Keycloak Documentation — Red Hat (2024).
• Okta: The State of SSO — Okta, Inc. (2023).