Единый вход

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

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

Архитектура единого входа основана на модели «доверенного посредника». Пользователь взаимодействует с системой через три ключевых компонента:

• Провайдер идентификации (IdP) — центральный сервер, который хранит учётные записи, проверяет подлинность пользователя и выдаёт токен (цифровое удостоверение) о успешной аутентификации.
• Сервис-провайдер (SP) — приложение или веб-сайт, к которому пользователь хочет получить доступ. Он не хранит пароли, а полагается на проверку со стороны IdP.
• Токен аутентификации — временный или постоянный цифровой ключ (например, JSON Web Token, SAML-утверждение или билет Kerberos), который содержит информацию о пользователе и времени сеанса.

Процесс типичного сценария SSO выглядит следующим образом:

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

История

Концепция единого входа возникла в 1970-х годах в академической среде. Одной из первых реализаций стала система Kerberos, разработанная в Массачусетском технологическом институте (MIT) в 1983 году. Она предназначалась для аутентификации пользователей в распределённых компьютерных сетях и до сих пор используется в операционных системах Windows (Active Directory) и Unix-подобных системах.

В 1990-х годах, с ростом числа корпоративных приложений, потребность в SSO усилилась. Появились коммерческие продукты, такие как Tivoli Access Manager (IBM) и Netegrity SiteMinder (ныне CA Single Sign-On). Параллельно развивались открытые протоколы: в 2002 году консорциум OASIS опубликовал стандарт SAML (Security Assertion Markup Language), ставший основой для федеративной аутентификации в веб-среде.

В 2010-х годах массовое распространение получили протоколы OAuth 2.0 и OpenID Connect, которые легли в основу современных решений SSO для потребительских интернет-сервисов — например, «Войти через Google», «Войти через VK ID» или «Войти через Яндекс ID». В России крупные платформы (Сбер, Mail.ru, Т-Банк) также внедрили собственные системы единого входа.

Виды и реализации

По типу управления

• Корпоративное SSO — развёртывается внутри организации для доступа к внутренним ресурсам (CRM, ERP, почта, файловые хранилища). Примеры: Microsoft Entra ID (ранее Azure Active Directory), FreeIPA, Keycloak.
• Федеративное SSO — объединяет несколько организаций или доменов. Пользователь одной компании может получить доступ к ресурсам другой компании без создания отдельной учётной записи. Реализуется через SAML, OpenID Connect или ADFS (Active Directory Federation Services).
• Социальное SSO — используется для входа на сторонние сайты через учётные записи социальных сетей или мессенджеров (VK ID, Яндекс ID, Apple ID, Google Account). Пользователь не передаёт пароль стороннему сайту — аутентификация происходит через API провайдера.

По способу хранения сеанса

• На основе cookie — после входа браузер сохраняет зашифрованную cookie-сессию, которая предъявляется всем сервисам в пределах одного домена. Недостаток: уязвимость для XSS-атак.
• На основе токенов — используется JWT (JSON Web Token) или SAML-утверждение. Токен может храниться в localStorage, sessionStorage или передаваться в HTTP-заголовке. Более безопасен, чем cookie, но требует управления сроком действия.
• На основе Kerberos — применяется в локальных сетях Windows. Пользователь получает билет от контроллера домена и предъявляет его серверам без ввода пароля.

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

• Удобство для пользователя — запоминается только один пароль, снижается количество попыток восстановления доступа.
• Снижение нагрузки на IT-поддержку — уменьшается число обращений по поводу забытых паролей.
• Повышение безопасности — централизованное управление учётными записями позволяет быстрее блокировать доступ при увольнении сотрудника или компрометации пароля.
• Единая политика паролей — администратор может задать требования к сложности пароля и частоту смены для всех систем одновременно.

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

• Единая точка отказа — если провайдер идентификации недоступен, пользователь теряет доступ ко всем связанным сервисам. Для снижения риска применяют кластеризацию IdP.
• Компрометация одного пароля — злоумышленник, получив доступ к учётной записи IdP, может проникнуть во все системы, подключённые к SSO. Для защиты требуется обязательное использование многофакторной аутентификации (MFA).
• Сложность внедрения — интеграция с устаревшими приложениями, не поддерживающими современные протоколы (SAML, OIDC), требует дополнительных шлюзов или адаптеров.
• Приватность — провайдер идентификации получает информацию о том, какие сервисы посещает пользователь. В корпоративной среде это может быть оправдано, но в потребительских сценариях вызывает вопросы.

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

• SAML 2.0 (Security Assertion Markup Language) — основан на XML, ориентирован на корпоративные веб-приложения. Широко используется в государственных и банковских системах.
• OAuth 2.0 — протокол делегирования доступа, не предназначенный для аутентификации напрямую. На его основе построены OpenID Connect и многие социальные SSO.
• OpenID Connect (OIDC) — надстройка над OAuth 2.0, добавляющая стандартизированный способ получения информации о пользователе. Используется в современных веб- и мобильных приложениях.
• Kerberos — сетевой протокол аутентификации, работающий на основе билетов. Применяется в Microsoft Active Directory и некоторых Unix-средах.
• LDAP (Lightweight Directory Access Protocol) — протокол для доступа к каталогам пользователей. Часто используется как бэкенд для хранения учётных записей в SSO-системах.

Примеры в России

• VK ID — единая система аутентификации экосистемы VK (организация признана в РФ иностранным агентом), позволяющая входить на все сервисы компании (VK, Почта Mail.ru, Облако, Карты) с одним паролем.
• Яндекс ID — централизованный аккаунт для сервисов Яндекса (Поиск, Почта, Диск, Музыка). Поддерживает вход по номеру телефона, QR-коду и биометрии.
• Сбер ID — единый профиль для доступа к сервисам Сбера (СберБанк, СберМаркет, СберЗдоровье). Использует OAuth 2.0 и OpenID Connect.
• Госуслуги — единая система идентификации и аутентификации (ЕСИА) для доступа к государственным и муниципальным услугам. Поддерживает федеративное SSO для ведомственных порталов.
• Keycloak — открытое решение для управления доступом и единым входом, активно применяется в российских компаниях для внутренних корпоративных систем.

Критика

Основная критика SSO связана с безопасностью: компрометация одного пароля ставит под удар все связанные сервисы. В ответ на это многие провайдеры (Яндекс, VK, Сбер) ввели обязательное использование двухфакторной аутентификации (одноразовые коды, Push-уведомления, биометрия). Также отмечается, что централизация данных о поведении пользователей создаёт риски для приватности: провайдер идентификации может отслеживать, какие ресурсы посещает человек. В России этот вопрос регулируется Федеральным законом «О персональных данных» (152-ФЗ) и требованиями к операторам идентификационных систем.

Источники

• Федеральный закон «О персональных данных» от 27.07.2006 № 152-ФЗ.
• Стандарт OASIS SAML 2.0, 2005.
• RFC 6749 — The OAuth 2.0 Authorization Framework, 2012.
• RFC 7519 — JSON Web Token (JWT), 2015.
• OpenID Connect Core 1.0 Specification, 2014.
• Документация Microsoft Entra ID (Azure Active Directory).
• Документация Keycloak (JBoss/Red Hat).
• Материалы сайтов VK ID, Яндекс ID, Сбер ID, ЕСИА (Госуслуги).