SAML vs OpenID Connect под капотом SSO

Разбираем, что лучше для SSO: SAML или OpenID Connect на примере системы беспарольной авторизации КриптоАРМ ID.

Что такое 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

Если обобщить все вышесказанное в одну табличку, то результат сравнения говорит сам за себя.

• OIDC по сравнению с SAML обладает повышенным уровнем безопасности, отвечающим последним требованиям безопасности.
• Простота настройки протокола OIDC лишь повышает уровень безопасности, так как возможностей для совершения ошибок значительно меньше.
• Возможность подключать нативные приложения и SPA в нынешнее время является обязательным требованием.
• Возможность не только аутентифицировать, но и авторизировать расширяют сферы применения протокола OIDC.

Протокол SAML не устарел, но он явно уступает протоколу OIDC по многим параметрам.

OIDC или SAML для SSO

Почему мы в своем SSO-проекте КриптоАРМ ID выбрали OIDC вместо SAML:

1. Безопасность: Избежание рисков, связанных с canonicalization XML и подписью вычисляемых значений. Уязвимости в SAML (например, Duo Security, 2018) позволяли эскалацию привилегий даже с включенным MFA.
2. Производительность: JSON в OIDC требует меньше ресурсов для парсинга, чем XML в SAML. Это критично для микросервисной архитектуры.
3. Опыт пользователя: Встроенная поддержка согласия (consent flow) в OIDC упрощает onboarding. SAML же требует кастомной реализации.
4. Сложность интеграции: OIDC значительно прост в настройках по сравнению SAML, что делает его более доступным и не требует высококвалифицированных специалистов.
5. SPA и нативные приложения: OIDC позволяет подключать SPA и нативные приложения, что для пользователей SSO является явным плюсом.

SAML позволяет работать с LDAP, а OIDC — нет, поэтому мы поддержали работу с AD по протоколу LDAP, и потребность в SAML окончательно отпала.
Официально SAML не признан устаревшим, но он явно уступает протоколу OIDC. Мы выбрали для КриптоАРМ ID протокол OIDC и не видим необходимости в реализации и поддержки протокола SAML.

Заключение

SAML 2.0 сыграл ключевую роль в эволюции SSO, но сегодня устарел: сложность интеграции, уязвимости canonicalization XML и отсутствие поддержки мобильных сценариев делают его аутсайдером. Альтернатива — стек OAuth 2.0 + OIDC:

• Безопасный за счет PKCE и JWT.
• Простой в реализации.
• Универсальный для веб, API и мобильных приложений.

Для КриптоАРМ ID это означает меньшие риски и быстрый вывод продукта на рынок.