Comments 18
SAML ориентирован на SSO и передачу утверждений (assertions), тогда как OAuth и OpenID Connect предлагают более гибкие механизмы авторизации и аутентификации, включая поддержку токенов доступа (access tokens) и идентификационных токенов (ID tokens).
Вот тут какая-то чушь написана, ID token по сути такой же assertion и содержит, только в формате JWT вместо SAML.
JSON и REST API упрощают интеграцию по сравнению с XML-базированным SAML.
Ну, некоторое упрощение чувствуется, но не сильное. От REST API тут одно название, спецификации что там, что там мозголомные.
Забыли, к слову, третий способ в сравнение добавить - WS-Federation.
OIDC значительно прост в настройках по сравнению SAML, что делает его более доступным и не требует высококвалифицированных специалистов.
Что-то не видел я никакой принципиальной разницы в простоте настройки.
Избежание рисков, связанных с canonicalization XML и подписью вычисляемых значений. Уязвимости в SAML (например, Duo Security, 2018) позволяли эскалацию привилегий даже с включенным MFA.
А можно подробности?
OIDC позволяет подключать SPA и нативные приложения, что для пользователей SSO является явным плюсом
Правильно ли я понимаю, что вся разница - в том, что SAML шлёт токен методом POST, в то время как OIDC использует GET, умещая всё что нужно в строку запроса? И у SPA с нативными приложениями сложности именно с получением тела запроса?
А можно подробности?
Когда начинаем работать с SAML, то проблемы начинаются ещё до начала работы с SAML, в частности, надо корректно работать с входящими XML (отключить external entity и пр.), чтобы избежать XXE и других уязвимостей. У json-а подобных проблем нет.
Ну, некоторое упрощение чувствуется, но не сильное. От REST API тут одно название, спецификации что там, что там мозголомные.
Не одно название. Отлаживать OIDC/OAuth2 действительно проще, достаточно иметь консоль и curl. И json на 10 строк более читаем чем xml от SAML-а.
Что-то не видел я никакой принципиальной разницы в простоте настройки.
Можно сравнить список рекомендаций по настройке:
Для OAuth2.0 https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html
Для SAML2.0 https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html
И в целом у OAuth2.0 всё более-менее сведено в одно место (отправная точка RFC 9700) и не надо бегать в поисках специалиста с сакральным знанием, как надо настраивать его.
Правильно ли я понимаю, что вся разница - в том, что SAML шлёт токен методом POST, в то время как OIDC использует GET, умещая всё что нужно в строку запроса? И у SPA с нативными приложениями сложности именно с получением тела запроса?
Речь про то, что в OIDC/OAuth2 есть разделение на пользователя и клиент, где клиентом может быть SPA, нативное приложение и любое другое. И для каждого клиента есть возможность управлять политиками и правилами. Например, каждому клиенту выдавать только свой набор ролей (у одного клиента запрашивать только логин/пароль, а для другого логин/пароль+второй фактор). Не говоря уже о ACR и LoA.
Кроме того, OAuth2 предлагает три варианта передачи токена:
параметр в GET-запросе - не желателен к использованию
параметр в Header - чаще всего используется
часть содержимого POST-запроса - реже используется.
Например, следующая ситуация, есть мобильное приложение, есть десктопное приложение, если веб-приложение. Используя эти разные клиенты, предоставляем доступ к одному и тому же ресурсу. При этом мы хотим при использовании десктопного приложения дать больше прав (например, десктопное приложение ставится только на доверенные ноуты в домене, есть поддержка цифровой подписи), а мобильному приложению хотим дать меньше прав (что-то сложное сделать нельзя, но получить статус, прочитать уведомление, прочитать краткое резюме). В OAuth2 это решается через клиенты, ACR, и у нас из коробки сразу же есть защита от mixup атак (это когда перехватили токен от мобилки, закинули в десктопное приложение и пытаемся получить расширенные права).
Как сделать разделение по правам между мобилкой и десктопным приложением в SAML2.0?
Автор ещё не указал, что OpenID Connect 1.0/OAuth 2.0 предоставляют возможности, которые отсутствуют в SAML2.0, например, управление сессией, чтобы клиент мог отслеживать сессию, мог обновить сессию, корректно завершить сессию (back-channel logout, front-channel logout, rp-initiated logout).
Или например динамическая регистрация клиента. Или аналог OAuth2 UMA2 (https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html).
Когда начинаем работать с SAML, то проблемы начинаются ещё до начала работы с SAML, в частности, надо корректно работать с входящими XML (отключить external entity и пр.), чтобы избежать XXE и других уязвимостей.
На стороне Relying Party ждать XXE-атаки со стороны Identity Provider глупо, поскольку тот может просто выписать токен на имя любого пользователя без всяких хитростей. Вот на стороне Identity Provider - да, надо защищаться от атак на XML. Но, с другой стороны, хороший переиспользуемый Identity Provider должен быть многопротокольным, а значит выбора "какой из протоколов использовать" не стоит, этот выбор есть только для Relying Party.
Можно сравнить список рекомендаций по настройке [,,,]
Там по второй ссылке 2/3 объёма - это рекомендации по работе с сертификатами, которые и для OIDC нужны. Единственная причина почему их нет по первой ссылке - потому что она касается исключительно OAuth2, без OIDC-надстройки.
Не говоря уже о ACR и LoA.
Это что вообще?
Как сделать разделение по правам между мобилкой и десктопным приложением в SAML2.0?
Зарегистрировать их как разные Relying Party со своими настройками?
Автор ещё не указал, что OpenID Connect 1.0/OAuth 2.0 предоставляют возможности, которые отсутствуют в SAML2.0, например, управление сессией [...]
Ну, они все есть в WS-Federation.
Единственная причина почему их нет по первой ссылке - потому что она касается исключительно OAuth2, без OIDC-надстройки.
И какие же требования к сертификатам в OIDC, кроме тех, которые предъявляются к OAuth2?
Это что вообще?
Authentication Context Class Reference
Ну, они все есть в WS-Federation.
В WS-Federation нет аналога UMA2.
Сам себе и отвечу, ACR есть в SAML2.0
И какие же требования к сертификатам в OIDC, кроме тех, которые предъявляются к OAuth2?
OIDC использует подписанные JWT, и требования, накладываемые на ключи для подписи, полностью аналогичные требованиям к ключам в SAML. Тот факт, что SAML использует сертификаты вместо JWK-описаний принципиально ничего не меняет.
Authentication Context Class Reference
Ну вроде ж в SAML оно есть, в чём проблема?
В WS-Federation нет аналога UMA2.
Ок (осталось только понять кому оно вообще нужно)
OIDC использует подписанные JWT, и требования, накладываемые на ключи для подписи, полностью аналогичные требованиям к ключам в SAML. Тот факт, что SAML использует сертификаты вместо JWK-описаний принципиально ничего не меняет.
Внезапно, но OAuth2 тоже может использовать подписанные JWT (RFC 9068) как и OIDC, более того что OAuth2, что OIDC используют одно и то же описание JWK. Требования к JWK описаны в RFC 8725. Вопрос же был в том, какие новые требования к сертификатам в OIDC кроме тех, которых предъявляются к OAuth2?
Да какая разница? Главное что в OAuth 2.0 Protocol Cheatsheet про обращение с ключами нет ни слова, а потому делать далеко идущие выводы на основе сравнения объёма списков рекомендаций странно.
SAML позволяет работать с LDAP, а OIDC нет
Можете подробнее раскрыть, что подразумевается под этой фразой?
Все дело в том что Active Directory работает с SAML напрямую через ADFS или другие SAML-совместимые IdP, поэтому SAML и используется часто в корпоративных средах.
Но если все перенести под капот SSO, то такой аспект можно парировать просто поддержав работу по протоколу LDAP и потребность в SAML резко сокращается.
Оставляем OIDC + LDAP и получаем простую и удобную схему, с большими возможностями чем просто SAML.
У Active Directory нет никакой прямой работы с SAML, только через AD FS. Которые, вообще-то, OIDC тоже поддерживает.
Откуда и возникает вопрос - какая такая "работа с LDAP" есть в SAML, которой не было бы в OIDC?
AD FS - это реализация SAML, причём не единственная, из того, что одна реализация спецификации использует LDAP, не следует, что и вся спецификация SAML2.0 использует LDAP. Кроме того AD FS умеет в OIDC, мы же не будем говорить, что OIDC работает с LDAP?
mayorovp
Я бы это обозначил не ограничением, а предусмотрительностью. Хотя может и стоит пересмотреть некоторые формы выражений, дабы избежать недопониманий.
SAML vs OpenID Connect под капотом SSO