Концепция Единой точки входа (SSO — Single Sign-On) — это огромный шаг вперед для удобства бизнеса. Вместо того чтобы заставлять сотрудников запоминать тридцать разных паролей от внутренних CRM, ERP, почты и таск-трекеров, компания разворачивает один центральный сервер аутентификации (Identity Provider, IdP). Пользователь вводит свои данные один раз, получает доступ ко всем нужным веб-приложениям и спокойно работает.
Однако, решая проблему удобства и централизации контроля, SSO кардинально меняет ландшафт рисков. Теперь у вас появляется единая критическая точка отказа. Если злоумышленник сможет скомпрометировать или обмануть ваш сервер IdP, он автоматически получит ключи от абсолютно всех корпоративных систем компании.
Давайте разберем архитектуру двух главных столпов современной федерации удостоверений — протоколов SAML и OpenID Connect (OIDC), а также поймем, как правильно настроить их интеграцию, чтобы не превратить SSO в сквозную дыру для хакеров.
SAML vs OIDC: Разные поколения одной идеи
Оба протокола созданы для одной цели — безопасно передать информацию о том, что пользователь успешно прошел проверку на центральном сервере, во внешнее рабочее приложение. Но делают они это на разных технологических уровнях.
SAML (Security Assertion Markup Language): Корпоративный тяжеловес
SAML 2.0 — это проверенный временем стандарт, построенный на базе XML и криптографии с открытым ключом. Он чаще всего используется в классических Enterprise-инфраструктурах и локальных веб-приложениях.
Как это работает: Приложение (Service Provider, SP) отправляет пользователя на сервер аутентификации (Identity Provider, IdP). После успешного входа IdP генерирует тяжелый XML-документ (SAML Assertion), который подписывается цифровой подписью IdP (а часто еще и шифруется). Этот документ передается обратно в приложение через браузер пользователя. Приложение проверяет подпись с помощью доверенного сертификата и впускает сотрудника.
Слабое место: Сложность XML. Исторически SAML страдает от уязвимостей, связанных с парсингом XML-документов. Самая известная атака — XML Signature Wrapping (XSW), когда хакер берет легитимное, подписанное сервером IdP утверждение, дописывает в этот же XML-файл свой вредоносный блок (например, меняет ID пользователя на администратора), и уязвимый парсер приложения проверяет подпись от старого блока, а права выдает по новому.
OIDC (OpenID Connect): Современный стандарт для API и облаков
OIDC — это тонкий слой идентичности, развернутый поверх протокола авторизации OAuth 2.0. Он разработан в эпоху расцвета мобильных приложений и микросервисной архитектуры. Вместо тяжелого XML здесь используется лаконичный формат JSON и токены JWT (JSON Web Tokens).
Как это работает: Приложение (Relying Party) отправляет запрос к IdP (OpenID Provider). После проверки пользователя IdP возвращает приложению легковесный ID Token (в формате JWT), содержащий базовые данные о сотруднике (имя, email, роли). Подлинность токена также проверяется с помощью асимметричного шифрования (обычно через набор ключей JWKS, публикуемых сервером IdP).
Слабое место: Наследование уязвимостей OAuth 2.0. Сам по себе OAuth 2.0 создавался для авторизации (делегирования прав), а не для аутентификации (проверки личности). Если инженер прикручивает чистый OAuth 2.0 вместо полноценного OIDC для организации входа, хакер может провести атаку Token Substitution (подмена токена), подсунув приложению чужой токен доступа, полученный в совершенно другом сервисе.
Сравнительный анализ протоколов федерации
Чтобы правильно выбрать фундамент для корпоративного контура, сопоставим особенности протоколов:
| Параметр | SAML 2.0 | OpenID Connect (OIDC) |
|---|---|---|
| Формат данных | XML | JSON / JWT |
| Транспортный уровень | В основном POST-запросы через браузер (Front-channel) | Прямые API-запросы между серверами (Back-channel) |
| Поддержка мобильных приложений | Плохая (крайне тяжело и неэффективно парсить XML на смартфонах) | Идеальная (создан для мобильных устройств и SPA) |
| Основная область применения | Традиционный Enterprise (on-premise софт, старые ERP, VPN) | Современные SaaS, микросервисы, облачные порталы, веб-API |
Архитектурные правила защиты SSO
Чтобы ваша централизованная система авторизации не стала легкой добычей для злоумышленников, при проектировании архитектуры необходимо жестко соблюдать четыре инженерных правила.
1. Защита токенов в веб-браузере
В OIDC-архитектуре приложение получает токены доступа (Access Token и ID Token). Если ваше веб-приложение сохраняет эти токены в LocalStorage или SessionStorage браузера, они становятся уязвимы для XSS-атак. Любой вредоносный скрипт, внедрившийся на страницу, сможет мгновенно украсть эти данные и угнать сессию сотрудника.
Решение: Токены и сессионные куки должны храниться строго с флагами HttpOnly и Secure. Это делает их физически недоступными для чтения через JavaScript в браузере. Еще более надежный паттерн — использование архитектуры BFF (Backend-for-Frontend), когда браузер вообще не видит токенов OIDC, а общается по старым безопасным сессиям со своим бэкэндом, который сам на серверном уровне управляет JWT-токенами.
2. Строгая валидация метаданных и подписей
Для SAML-интеграций критически важна правильная конфигурация парсера на стороне приложения.
Решение: Никогда не доверяйте параметрам адреса IdP, переданным в самом запросе. Все настройки доверия (сертификаты IdP, URL-адреса endpoints) должны быть жестко прописаны в конфигурационных файлах приложения статически. Парсер XML должен быть аппаратно защищен от внешних сущностей (отключите поддержку External Entities / XXE в коде парсера), чтобы хакер не мог заставить сервер прочитать локальные файлы ядра ОС.
3. Миграция на безопасные Flow в OIDC
В протоколе OIDC (OAuth2) существует несколько сценариев обмена данными (Flows). Старый сценарий Implicit Flow (когда токен возвращался напрямую в строке браузера после авторизации) сегодня признан небезопасным (Deprecated).
Решение: Используйте исключительно Authorization Code Flow с расширением PKCE (Proof Key for Code Exchange). В этом сценарии приложение сначала получает временный одноразовый код, а затем сам бэкэнд приложения запрашивает реальный токен у IdP по защищенному каналу "сервер-сервер", подтверждая легитимность запроса уникальным криптографическим секретом (Code Verifier). Это полностью исключает перехват токена на уровне браузера.
4. Локальный хостинг сервера удостоверений (IdP)
Для крупного бизнеса отдавать управление всеми учетными записями во внешние публичные облачные сервисы (IDaaS) — неоправданный риск. При падении магистрального интернета или блокировке облачного провайдера вся работа компании мгновенно встанет.
Сервер IdP (например, на базе Keycloak или отечественных Enterprise-решений каталогов) необходимо разворачивать on-premise внутри собственного периметра. Использование локальных платформ виртуализации позволяет обеспечить максимальную отказоустойчивость ядра авторизации. Вы можете настроить кластеризацию серверов IdP на разных физических узлах гипервизора, гарантируя аптайм 99.99%, а весь трафик аутентификации останется внутри защищенного ЦОД, не выходя в публичную сеть.
Частые вопросы
Что такое Single Sign-Out (SLO) и почему с ним всегда возникают проблемы?
Single Sign-On позволяет войти во все системы одним кликом, а Single Sign-Out должен синхронно завершить сессии во всех приложениях, когда пользователь нажимает кнопку «Выход» на центральном портале. На практике реализовать это сложно: IdP должен отправить специальные бэкэнд-запросы (или инвалидировать куки) во все тридцать интеграций. Если хотя бы одно приложение настроено некорректно и проигнорирует запрос от IdP, пользователь останется авторизован в этой конкретной системе, что создает риск утечки, если он ушел с рабочего места, думая, что полностью разлогинился.
Можно ли использовать JWT-токены без шифрования?
Большинство JWT-токенов в OIDC используют только механизм цифровой подписи (формат JWS), но не шифруются (формат JWE). Это означает, что данные внутри токена (payload) закодированы в обычный Base64. Любой человек, перехвативший токен, может прочитать его содержимое: имя пользователя, его роли и email. Это безопасно до тех пор, пока токен передается строго по шифрованному каналу HTTPS и внутри него нет чувствительных данных (например, паролей или финансовых токенов). Если вам нужно передать конфиденциальную информацию внутри JWT, использование шифрования JWE становится обязательным.
В чем разница между Аутентификацией и Авторизацией в контексте SSO?
Это фундаментальное различие. Аутентификация — это проверка того, кем пользователь является на самом деле (протокол OIDC / SAML отвечает на вопрос: «Да, это действительно инженер Иванов»). Авторизация — это проверка прав и разрешений этого пользователя (протокол OAuth 2.0 отвечает на вопрос: «Имеет ли инженер Иванов право скачивать этот финансовый отчет из базы?»). SSO-системы сначала проводят аутентификацию сотрудника, а затем передают приложению набор его ролей, на основе которых само приложение принимает решение об авторизации внутри своих внутренних модулей.