Оригинальный OpenID 2.0 против SAML
Это два разных протокола аутентификации, и они отличаются на техническом уровне.
На расстоянии различия начинаются, когда пользователи инициируют аутентификацию. С OpenID логин пользователя обычно является HTTP-адресом ресурса, который отвечает за аутентификацию. С другой стороны, SAML основан на явном доверии между вашим сайтом и поставщиком удостоверений, поэтому довольно редко принимают учетные данные с неизвестного сайта.
Идентификации OpenID легко обойти по сети. В качестве разработчика вы можете просто принять пользователей из разных поставщиков OpenID. С другой стороны, поставщик SAML обычно должен быть заранее закодирован, и вы объединяете свое приложение только с выбранными поставщиками удостоверений. Можно сузить список принятых провайдеров идентификации OpenID, но я думаю, что это противоречит общей концепции OpenID.
С OpenID вы принимаете идентификационные данные, поступающие с произвольных серверов. Кто-то утверждает, что это http://someopenid.provider.com/john.smith
. Как вы собираетесь сопоставить это с пользователем в вашей базе данных? Каким-то образом, например, сохраняя эту информацию с новой учетной записью и распознавая ее, когда пользователь снова заходит на ваш сайт. Обратите внимание, что никакой другой информации о пользователе (включая его имя или адрес электронной почты) нельзя доверять!
С другой стороны, если существует явное доверие между вашим приложением и провайдером идентификатора SAML, вы можете получить полную информацию о пользователе, включая имя и адрес электронной почты, и этой информации можно доверять только из-за отношения доверия. Это означает, что вы склонны полагать, что провайдер Id каким-то образом проверял всю информацию, и вы можете доверять ей на уровне приложения. Если пользователи приходят с токенами SAML, выпущенными неизвестным поставщиком, ваше приложение просто отклоняет аутентификацию.
OpenID Connect против SAML
(раздел добавлен 07-2017, расширен 08-2018)
Этот ответ датируется 2011 годом, и тогда OpenID обозначал OpenID 2.0 . Позже, где-то в 2012 году была опубликована OAuth2.0 , а в 2014 году OpenID Connect (более подробная временная шкала здесь ).
Для тех, кто читает это в настоящее время - OpenID Connect - это не тот OpenID, исходный ответ относится к , скорее это набор расширений для OAuth2.0.
Хотя этот ответ может пролить некоторый свет с концептуальной точки зрения, очень краткая версия для тех, кто идет с фоном OAuth2.0, заключается в том, что OpenID Connect на самом деле является OAuth2.0, но добавлен стандартный способ запроса информации о пользователе после получения токена доступа.
Обращаясь к исходному вопросу - в чем главное отличие OpenID Connect (OAuth2.0) от SAML, как строится доверительное отношение между приложением и поставщиком удостоверений:
SAML строит доверительные отношения на цифровой подписи, токены SAML, выдаваемые поставщиком удостоверений, являются подписанными XML, приложение проверяет саму подпись и сертификат, который она предоставляет. Информация о пользователе включена в токен SAML, помимо прочего.
OAuth2 строит доверительные отношения на прямом HTTP-вызове из приложения к идентификатору. Запрос содержит токен доступа (полученный приложением во время прохождения протокола), а ответ содержит информацию о пользователе.
OpenID Connect дополнительно расширяет это, чтобы сделать возможным получение идентификатора без этого дополнительного шага, связанного с вызовом из приложения поставщику идентификационных данных. Идея основана на том факте, что поставщики OpenID Connect на самом деле выдают два токена, access_token
, тот же OAuth2.0 выдает и новый, id_token
, который является JWT токен, подписанный провайдером идентификации. Приложение может использовать токен идентификатора для установления локального сеанса на основе утверждений, включенных в токен JWT, но токен идентификатора нельзя использовать для дальнейших запросов других служб, такие вызовы сторонним службам должны по-прежнему использовать токен доступа. Тогда вы можете рассматривать OpenID Connect как гибрид между SAML2 (подписанный токен) и OAuth2 (токен доступа), поскольку OpenID Connect включает в себя и то, и другое.