SAML vs OpenID Connect под капотом SSO
Доброго времени суток! Я Мирошин Роман, руководитель проекта Trusted.ID. Занимаясь разработкой SSO, периодически получаю комментарии и вопросы, почему мы выбрали протокол OIDC вместо SAML и почему не включаем его в планы на поддержку. В этой статье я постараюсь рассказать, о причинах такого решения.
Что такое SSO
Single Sign-On (SSO) — это механизм, позволяющий пользователям получать доступ к нескольким приложениям и сервисам после однократной аутентификации. Как студенческий билет в университетском кампусе, он открывает двери в библиотеку, спортзал и столовую без повторных проверок.
Важность SSO раскрывается в трех аспектах:
Удобство: Пользователям не нужно запоминать десятки паролей.
Безопасность: Централизованный контроль снижает риски утечек и упрощает внедрение MFA.
Эффективность: IT-отделы тратят меньше времени на сброс паролей и управление учетными записями.
В корпоративных средах SSO — не роскошь, а стандарт для интеграции облачных сервисов (SaaS), порталов и внутренних систем.
Для чего нужен протокол в SSO
Протокол — это определенный набор правил и процедур, определяющих, как различные сервисы и системы должны взаимодействовать друг с другом для передачи, обработки и защиты данных.
Другими словами, протокол в SSO определяет набор возможностей в системе:
SAML и OIDC (RFC 7522 и SPEC) обеспечивают обмен аутентификационными данными между провайдерами и сервисами.
OAuth 2.0 (RFC 6749) отвечает за делегирование доступа.
Kerberos (RFC 4120) реализует централизованную аутентификацию в корпоративных сетях.
WebAuthn (W3C) позволяет использовать биометрию и аппаратные ключи для входа.
Благодаря этим и другим протоколам пользователи проходят аутентификацию один раз и получают доступ к разным сервисам без повторного ввода пароля.
SAML vs OpenID Connect
По своему назначению эти протоколы достаточно идентичны, они оба обеспечивают обмен аутентификационными данными между провайдерами и сервисами. Именно по этому всегда появляется вопрос, а кто из них лучше? Для того чтобы ответить на этот вопрос, необходимо более детально изучить их историю и особенности работы.
Протокол SAML
Security Assertion Markup Language (SAML 2.0) — протокол для обмена аутентификационными данными в формате XML. Его архитектура разработана в начале 2000-х.
Этот протокол зарекомендовал себя с течением времени и широко используется во многих системах. Но у него есть ряд особенностей, которые осложняют его использование:
Сложность интеграции: SAML использует XML, что делает его громоздким для разработки и отладки по сравнению с JSON-базированными протоколами, такими как OAuth 2.0 и OpenID Connect.
Ограниченная поддержка мобильных и современных приложений: SAML изначально разрабатывался для веб-приложений и менее удобен для мобильных приложений или API-driven архитектур. OAuth 2.0 и OpenID Connect лучше подходят для таких случаев.
Меньшая гибкость: SAML ориентирован на SSO и передачу утверждений (assertions), тогда как OAuth и OpenID Connect предлагают более гибкие механизмы авторизации и аутентификации, включая поддержку токенов доступа (access tokens) и идентификационных токенов (ID tokens).
Протокол OpenID Connect
OpenID Connect (OIDC) — протокол аутентификации, расширяющий протокол OAuth 2.0 и добавляющий возможности идентификации пользователей. Он сочетает авторизацию и аутентификацию, используя JSON Web Token (JWT) для передачи данных о пользователе. Разработан в 2014 году.
Этот протокол считается более современным и рекомендуемым для новых систем. Данный протокол имеет ряд улучшений:
Простота: JSON и REST API упрощают интеграцию по сравнению с XML-базированным SAML.
Гибкость: Подходит для веб, мобильных приложений и API.
Безопасность: Поддержка JWT и PKCE.
Широкая поддержка: Совместим с Google, Okta, Auth0, Azure AD.
Сравнение протоколов SAML vs OpenID Connect
Если обобщить все вышесказанное в одну табличку, то результат сравнения говорит сам за себя.
Критерий |
SAML 2.0 |
OIDC |
Безопасность |
⚠️ Риски canonicalization |
✅ JWT-подписи + PKCE |
Формат данных |
XML (тяжелый) |
JSON (легкий) |
Мобильность |
❌ Нет поддержки |
✅ Нативные приложения + SPA |
Сложность интеграции |
Высокая (сертификаты, XML) |
Низкая |
Аутентификация |
✅ |
✅ |
Авторизация |
❌ |
✅ |
OIDC по сравнению с SAML обладает повышенным уровнем безопасности, отвечающим последним требованиям безопасности.
Простота настройки протокола OIDC лишь повышает уровень безопасности, так как возможностей для совершения ошибок значительно меньше.
Возможность подключать нативные приложения и SPA в нынешнее время является обязательным требованием.
Возможность не только аутентифицировать, но и авторизировать расширяют сферы применения протокола OIDC.
Протокол SAML не устарел, но он явно уступает протоколу OIDC по многим параметрам.
OIDC или SAML для SSO
Собрав всю информацию воедино, то вывод о причине того, что мы в своем SSO проекте Trusted.ID выбрали OIDC вместо SAML, очевиден, но все-равно подведу итоги:
Безопасность: Избежание рисков, связанных с canonicalization XML и подписью вычисляемых значений. Уязвимости в SAML (например, Duo Security, 2018) позволяли эскалацию привилегий даже с включенным MFA.
Производительность: JSON в OIDC требует меньше ресурсов для парсинга, чем XML в SAML. Это критично для микросервисной архитектуры.
Опыт пользователя: Встроенная поддержка согласия (consent flow) в OIDC упрощает onboarding. SAML же требует кастомной реализации.
Сложность интеграции: OIDC значительно прост в настройках по сравнению SAML, что делает его более доступным и не требует высококвалифицированных специалистов.
SPA и нативные приложения: OIDC позволяет подключать SPA и нативные приложения, что для пользователей SSO является явным плюсом.
«Стойте! Ведь SAML позволяет работать с LDAP, а OIDC нет и это перечеркивает всю нашу аналитическую работу!». Вовсе нет, зная о проблемах протокола SAML, мы поддержали работу с AD по протоколу LDAP и потребность в SAML окончательно отпала.
Официально SAML не признан устаревшим, но он явно уступает протоколу OIDC. Мы выбрали для своего проекта OIDC и не видим необходимости в реализации и поддержки протокола SAML.
Заключение
SAML 2.0 сыграл ключевую роль в эволюции SSO, но сегодня устарел: сложность интеграции, уязвимости canonicalization XML и отсутствие поддержки мобильных сценариев делают его аутсайдером. Альтернатива — стек OAuth 2.0 + OIDC:
Безопасный за счет PKCE и JWT.
Простой в реализации.
Универсальный для веб, API и мобильных приложений.
Для проектов вроде Trusted.ID это означает меньшие риски и быстрый вывод продукта на рынок.
Какие протоколы используете вы? Сталкивались ли с проблемами SAML? Делитесь опытом в комментариях!