OIDC против SAML: почему монструозный XML из нулевых пора похоронить

Парсить мегабайты XML с каноникализацией и бояться XML Signature Wrapping — сомнительное удовольствие для инженера в 2026 году. Сравниваем SAML 2.0 и OpenID Connect на практике и объясняем, почему переход на JSON и JWT спасает проект.

Эволюция протоколов федерации: SAML против OIDC

Если вы когда-нибудь в пятницу вечером пытались подружить корпоративный сервис с корпоративным IdP по протоколу SAML 2.0, вы наверняка знаете этот специфический холодок внутри.

Вы смотрите в дампы трафика, где летает чудовищная простыня XML на 12 килобайт в Base64. Внутри — тридцать вложенных тегов <saml2p:Response>, пространства имён с URL-адресами несуществующих стандартов консорциума OASIS, блок <ds:X509Certificate> на пол-экрана и ошибка:

Signature verification failed: XML canonicalization error.

Что пошло не так? Пробел. Один невидимый пробел или символ переноса строки в середине файла сломал алгоритм каноникализации C14N, и подпись превратилась в тыкву.

Добро пожаловать в прекрасный мир SAML 2.0 — стандарта, который был утверждён в марте 2005 года, за два года до выхода первого iPhone.

Давайте разберёмся, почему монструозный XML из эпохи SOAP пора отправить на заслуженную пенсию, и почему современная индустрия безоговорочно выбрала OpenID Connect (OIDC).

---

Главные грехи SAML 2.0

SAML создавался во времена, когда корпоративный софт писали на Java, гоняли SOAP-запросы, а разработчики всерьёз верили, что схемы XSD спасут человечество.

Сегодня попытка внедрить SAML в современный стек вызывает непреодолимую тоску по четырём причинам:

1. Вес и раздутость (XML Bloat)

Обычный SAML Assertion — это тяжеленный мешок XML-разметки. Чтобы передать три атрибута (логин, имя и email), SAML генерирует документ на 5–15 килобайт.

Поскольку вся эта масса передаётся через редиректы браузера в параметрах HTTP POST или даже HTTP GET, вы регулярно упираетесь в лимиты веб-серверов на размер URI и заголовков.

2. Адская каноникализация (XML-DSig и C14N)

В JSON всё просто: взяли байты, посчитали HMAC или RSA-подпись, положили в третью часть JWT через точку.

В XML всё устроено извращённо: перед проверкой подписи парсер обязан выполнить «каноникализацию» — привести пробелы, атрибуты и переносы строк к сакральному эталону.

Разные парсеры (Java, libxml2, Python, Go) делают это чуть-чуть по-разному. Результат — недели дебага на тему «почему в тестовой среде работает, а на проде отваливается».

3. Дыры в безопасности: XML Signature Wrapping (XSW)

Из-за гибкости спецификации XML цифровой подписью заверяется не весь документ целиком, а отдельный узел с атрибутом ID.

Это породило целый класс критических уязвимостей — XML Signature Wrapping. Атакующий дублирует узел с пользователем, подсовывает чужую валидную подпись во второй узел, и уязвимый парсер проверяет подпись Васи, а права выдаёт админу Пете. Библиотеки для работы с SAML регулярно латают от подобных атак до сих пор.

4. Несовместимость с мобилками и SPA

Попробуйте реализовать чистый SAML Web Browser SSO Profile в нативном мобильном приложении на Flutter/Swift или в React-одностраничнике без бэкенда. Вы проклянёте всё. SAML фундаментально завязан на редиректы браузера с отправкой скрытых HTML-форм (HTTP-POST Binding).

---

Почему OpenID Connect (OIDC) — это глоток чистого воздуха

OpenID Connect, появившийся в 2014 году, не стал изобретать велосипед. Он взял проверенную базу авторизации OAuth 2.0 и добавил к ней стандартизированный слой идентификации.

| Параметр | SAML 2.0 | OpenID Connect (OIDC) |

|---|---|---|

| Формат данных | Монструозный XML с пространствами имён | Чистый JSON и JWT (RFC 7519) |

| Вес токена | 5 000 – 15 000 байт | 500 – 1 200 байт |

| Подпись и криптография | XML-DSig / Canonicalization | JWS / JWK (стандартная проверка хеша) |

| Настройка | Ручной обмен гигантскими XML-файлами метаданных | Авто-конфигурация через эндпоинт /.well-known/openid-configuration |

| Поддержка клиентов | Только классический веб в браузере | Любые клиенты: Веб, SPA, iOS, Android, CLI, микросервисы |

---

Как это выглядит для инженера на практике

Вместо того чтобы вручную генерировать сертификаты, скачивать XML-метаданные и закидывать их через форму настроек, интеграция с OIDC-шлюзом OwnGate выглядит так:

1. Вы указываете в приложении один URL:

https://auth.company.local/.well-known/openid-configuration

2. Приложение само стягивает эндпоинты авторизации, токенов и открытые ключи валидации;

3. После входа приложение получает компактный JWT (ID Token), который моментально декодируется в читаемый JSON:


{

  "sub": "usr_948201",

  "name": "Алексей Смирнов",

  "email": "a.smirnov@company.ru",

  "groups": ["DevOps", "Admins"],

  "exp": 1789073400

}

Никаких парсеров XML, никаких рисков XSW-атак, никакого шаманства с пробелами.

---

Есть ли хоть одна причина оставаться на SAML?

Честный ответ — ровно одна: древний enterprise-легаси софт.

Если ваша компания обязана подключаться к старым инсталляциям SAP, Salesforce из 2010 года или специфическим государственным шлюзам, которые умеют только SAML 2.0 — от него никуда не деться.

Именно поэтому современный шлюз доступа (OwnGate) умеет работать в гибридном режиме: он может отдавать наружу лёгкий и быстрый OIDC для 99% ваших современных сервисов (GitLab, Grafana, Nextcloud, Sentry), сохраняя совместимость с SAML для капризных динозавров.

Но если перед вами стоит выбор протокола для нового сервиса компании — хороните SAML без колебаний. Инженерное спокойствие и простота отладки стоят дороже ностальгии по нулевым.