Доброго времени суток! Я Мирошин Роман, руководитель проекта 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

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

• OIDC по сравнению с SAML обладает повышенным уровнем безопасности, отвечающим последним требованиям безопасности.

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

• Возможность подключать нативные приложения и SPA в нынешнее время является обязательным требованием.

• Возможность не только аутентифицировать, но и авторизировать расширяют сферы применения протокола OIDC.

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

OIDC или SAML для SSO

Собрав всю информацию воедино, то вывод о причине того, что мы в своем SSO проекте Trusted.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 нет и это перечеркивает всю нашу аналитическую работу!». Вовсе нет, зная о проблемах протокола SAML, мы поддержали работу с AD по протоколу LDAP и потребность в SAML окончательно отпала.

Официально SAML не признан устаревшим, но он явно уступает протоколу OIDC. Мы выбрали для своего проекта OIDC и не видим необходимости в реализации и поддержки протокола SAML.

Заключение

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

• Безопасный за счет PKCE и JWT.

• Простой в реализации.

• Универсальный для веб, API и мобильных приложений.

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

Какие протоколы используете вы? Сталкивались ли с проблемами SAML? Делитесь опытом в комментариях!