SAML или OIDC: выбор протокола единого входа

SAML или OIDC — это выбор протокола, на котором строится единый вход (single sign-on, SSO). В SAML 2.0 (стандарт OASIS, март 2005 года) поставщик удостоверений (identity provider, IdP) подписывает XML-утверждение о пользователе, и браузер доставляет это утверждение поставщику услуг (service provider). OpenID Connect (Core 1.0, февраль 2014 года, также ISO/IEC 26131:2024) добавляет к OAuth 2.0 уровень идентификации: поставщик выпускает подписанный JWT — ID-токен, обычно через поток кода авторизации (authorization code flow), и в том же обмене может выдать токены доступа к API.

Коротко о главном

Как каждый протокол выполняет вход пользователя

В SAML поставщик услуг перенаправляет браузер к поставщику удостоверений с запросом AuthnRequest. После входа IdP возвращает HTML-форму, которая POST-запросом отправляет закодированный в base64 ответ Response с утверждением: издатель, субъект, ограничение аудитории, интервал действия, атрибуты и XML-подпись. Поставщик услуг проверяет подпись сертификатом из метаданных IdP и сверяет условия.

В OpenID Connect клиент выполняет перенаправление на эндпоинт авторизации поставщика с параметрами scope=openid, state, nonce и challenge PKCE. Поставщик возвращает одноразовый код на URI перенаправления; клиент обменивает этот код на эндпоинте токенов на ID-токен и токен доступа через прямое TLS-соединение, поэтому токены никогда не проходят через адресную строку браузера.

Скрипт ниже читает оба вида конфигурации у одного и того же поставщика (20 октября 2026 года, curl и jq 1.8.1). При повторных запросах размер метаданных SAML менялся от 28 до 32 КБ, а число ключей в JWKS — от 7 до 8, потому что отвечали разные серверы.

#!/bin/sh
base=https://login.microsoftonline.com/common
echo "== OpenID Connect discovery"
curl -s "$base/v2.0/.well-known/openid-configuration" -o oidc.json
echo "bytes: $(wc -c < oidc.json | tr -d ' ')"
jq -c '{id_token_signing_alg_values_supported, response_types_supported}' oidc.json
curl -s "$(jq -r .jwks_uri oidc.json)" | jq -c '{jwks_keys: (.keys | length), kty: ([.keys[].kty] | unique)}'

echo "== SAML 2.0 metadata"
curl -s "$base/FederationMetadata/2007-06/FederationMetadata.xml" -o saml.xml
echo "bytes: $(wc -c < saml.xml | tr -d ' ')"
grep -o 'SignatureMethod Algorithm="[^"]*"' saml.xml | sort -u
grep -o 'SingleSignOnService Binding="[^"]*"' saml.xml | sort -u
echo "distinct certificates: $(grep -o '<X509Certificate>[^<]*' saml.xml | sort -u | wc -l | tr -d ' ')"
rm -f oidc.json saml.xml

== OpenID Connect discovery
bytes: 1728
{"id_token_signing_alg_values_supported":["RS256"],"response_types_supported":["code","id_token","code id_token","id_token token"]}
{"jwks_keys":7,"kty":["RSA"]}
== SAML 2.0 metadata
bytes: 28179
SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
distinct certificates: 5

Что обязана проверить доверяющая сторона

SAML: проверьте XML-подпись сертификатом IdP, который вы указали в настройках (никогда — сертификатом, вложенным в сообщение), и убедитесь, что подпись охватывает именно то утверждение, с которым работает ваш код; затем проверьте Issuer, Destination, InResponseTo, AudienceRestriction, NotBefore и NotOnOrAfter и отклоняйте повторно присланные ответы. Сложность заложена в самой структуре. XML Signature подписывает элементы, на которые ссылается по ID, после канонизации, поэтому документ может содержать корректно подписанный элемент и другой, неподписанный, который приложение обработает вместо него. В 2012 году Соморовски и его коллеги обнаружили такое обёртывание подписи (signature wrapping) в 11 из 14 фреймворков SAML; в 2024 и 2025 годах библиотеку ruby-saml (её использует GitLab) снова пришлось исправлять (CVE-2024-45409, CVE-2025-25291 и CVE-2025-25292), потому что два XML-парсера в одной библиотеке по-разному читали один и тот же документ.

OpenID Connect (Core, § 3.1.3.7): проверьте JWS ключом из JWKS поставщика, выбранным по kid, и с тем алгоритмом, который вы ожидаете; затем проверьте iss, aud (ваш идентификатор клиента), exp, iat и отправленный вами nonce. У JSON одно дерево разбора, а подпись охватывает ровно те байты, которые были получены, поэтому проблемы обёртывания нет; остаются другие ловушки: приём неожиданных алгоритмов, пропуск проверки aud и слабое сопоставление URI перенаправления, которые разбирают действующие рекомендации по безопасности OAuth (RFC 9700, январь 2025 года). Валидатор токенов OIDC выполняет эти проверки по актуальному JWKS поставщика, а инспектор SAML показывает, какой элемент на самом деле охвачен подписью.

Что когда выбирать

• Новые приложения, мобильные и одностраничные приложения, API: OpenID Connect с потоком кода авторизации и PKCE.
• Продажа SaaS корпоративным клиентам: поддерживайте оба протокола; у многих клиентов команды управления удостоверениями по-прежнему в первую очередь настраивают SAML.
• Федерации науки и образования (eduGAIN, InCommon): SAML со сводными файлами метаданных; OpenID Federation 1.0 (окончательная версия с февраля 2026 года) проходит пилотное внедрение в eduGAIN, но пока не стала нормой.
• Госсектор и регулируемые отрасли: следуйте профилю, обязательному в вашей экосистеме; открытый банкинг и аналогичные регуляторные режимы используют FAPI 2.0 — усиленный профиль OAuth и OpenID Connect.
• Создание пользователей и групп (provisioning): ни тот ни другой; используйте SCIM 2.0 (RFC 7643 и RFC 7644) вместе с любым из протоколов.

Заметки о миграции

1. Запустите оба протокола параллельно: настройте приложение OIDC в том же поставщике удостоверений и до переключения сопоставьте с существующими учётными записями тот же идентификатор пользователя (sub или постоянный атрибут).
2. Явно сопоставьте атрибуты с утверждениями (claims); имена атрибутов SAML (часто это URN) редко совпадают с именами утверждений OIDC, а для утверждений о группах может понадобиться отдельный вызов API, если у пользователей много групп.
3. Используйте сертифицированную библиотеку для OpenID Connect, включите получение документа обнаружения и кеширование JWKS с обновлением при неизвестном kid и зафиксируйте список допустимых алгоритмов.
4. Усильте защиту того, что остаётся на SAML: обновите библиотеку, требуйте подписанных утверждений, отклоняйте документы с несколькими утверждениями или с DTD и отслеживайте истечение срока действия сертификатов в метаданных партнёров.
5. Отдельно спланируйте выход: сопоставьте SAML Single Logout с OIDC Back-Channel Logout там, где сессии должны завершаться централизованно.
6. Выводите подключение SAML из эксплуатации только тогда, когда журналы за полный бизнес-цикл не покажут ни одного входа через SAML.

Источники

• OASIS SAML 2.0 Core и привязки (Bindings)
• OpenID Connect Core 1.0 (§ 3.1.3.7, проверка ID-токена)
• OpenID Connect Discovery 1.0
• OpenID Connect Back-Channel Logout 1.0
• RFC 9700, рекомендации по безопасности OAuth 2.0 (Best Current Practice)
• RFC 7636, PKCE и RFC 8252, OAuth для нативных приложений
• W3C XML Signature Syntax and Processing 1.1
• Somorovsky и др., On Breaking SAML, USENIX Security 2012