В чем разница между OpenID и SAML?

Ответ 1

Оригинальный 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 это на самом деле OAuth 2.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 включает в себя и то, и другое.

Ответ 2

OpenID и SAML2 основаны на одной и той же концепции федеративной идентификации. Ниже приведены некоторые из различий между ними..

SAML2 поддерживает единый выход, но OpenID не поддерживает
Поставщики услуг SAML2 связаны с поставщиками удостоверений SAML2, но проверяющие стороны OpenID не связаны с поставщиками OpenID. OpenID имеет протокол обнаружения, который динамически обнаруживает соответствующий поставщик OpenID, как только задан OpenID. SAML имеет протокол обнаружения, основанный на протоколе службы обнаружения Identity Provider.
С SAML2 пользователь связан с IdP SAML2 - ваш идентификатор SAML2 действителен только для IdP SAML2, который его выдал. Но с OpenID у вас есть свой идентификатор и вы можете сопоставить его с любым провайдером OpenID по вашему желанию.
SAML2 имеет различные привязки, в то время как OpenID имеет только привязку HTTP
SAML2 может быть инициирован либо поставщиком услуг (SP), либо поставщиком удостоверений (IdP). Но OpenID всегда SP инициируется.
SAML 2 основан на XML, а OpenID - нет.
Большая часть приложений, разработанных за последние 3 года, поддерживала только OpenID Connect.
92% запросов на аутентификацию 8B+, отправленных Microsoft Azure AD в мае 2018 года, были получены из приложений с поддержкой OpenID Connect.

Ответ 3

Оставляя технические детали в стороне, опаздывая на вечеринку, я понимаю, что самая большая разница между SAML и другими стандартами аутентификации (в том числе OpenID) заключается в том, что

SAML требует, чтобы провайдер идентификации (IDP) и провайдер услуг (SP) знали друг друга заранее, предварительно настроив статическую аутентификацию и авторизацию. OpenId (+Connect) не имеет такого требования.

Это важно для ВПЛ, которым нужен полный контроль над доступом к данным. Частью стандарта является настройка того, что предоставляется конкретным SP.

Например, банк может не захотеть, чтобы его пользователи имели доступ к каким-либо услугам, кроме некоторых предопределенных (из-за правил или других строгих правил безопасности).

Это не означает, что OpenId IDP не может применять такое ограничение. Реализатор OpenID может контролировать доступ, но это не цель OpenID.

За исключением предопределенной, строгой, статической разницы в управлении доступом, концептуально (не технически) OpenID Connect и SAML схожи.

В итоге, если вы SP, вы должны поддерживать то, что требуется вашим клиентам:

Если ваш клиент - это отдельный конечный пользователь (например, с помощью идентификатора Google), забудьте о SAML. Используйте OpenID Connect.
Если ваш клиент - это банк, который хочет, чтобы его сотрудники использовали ваш сервис и экспортировали только статический список данных, которые он предоставит вашему сервису, банк, вероятно, пожелает, чтобы вы поддержали SAML. У банка может быть реализация OpenID с ограничением клиента, что будет вашим счастливым днем :)

Ответ 4

@Prabath: OpenID поддерживает единый вход.

На вопрос: OpenID включает аутентификацию пользователя через централизованные поставщики удостоверений (IdP) на нескольких доверенных веб-сайтах или полагающихся сторонах (RP). Когда пользователь аутентифицируется, он может свободно перемещаться между несколькими сайтами с поддержкой OpenID без повторного ввода их учетных данных.

SAML - это открытый отраслевой стандарт на основе XML для обмена информацией об аутентификации и авторизации пользователей (утверждения безопасности) между поставщиками услуг и потребителями.

Ответ 5

Как SAML, так и OpenID могут выступать в качестве провайдера идентификации (сокращенно IdP), то есть децентрализованного протокола аутентификации (идентификация единого входа).

Е Д ssertion М arkup л anguage (SAML) представляет собой набор профилей для обмена данными аутентификации и авторизации между доменами безопасности. В модели домена SAML поставщик удостоверений представляет собой особый тип полномочий проверки подлинности. В частности, провайдер идентификации SAML - это системный объект, который выдает утверждения аутентификации в сочетании с профилем единого входа SAML. Проверяющая сторона, которая использует эти утверждения проверки подлинности, называется поставщиком услуг SAML. Источник

Вывода пера ID С кий подключить (РСИН) представляет собой слой аутентификации поверх OAuth 2.0, рамка авторизации. Стандарт контролируется Фондом OpenID. OAuth предназначен для протокола авторизации, а не протокола аутентификации и OpenID, специально разработанного в качестве протокола аутентификации. OIDC использует простые веб-токены JSON (JWT), их легче использовать с помощью JavaScript.

Сценарий использования:

Используйте OAuth, если ваши пользователи могут просто захотеть войти через Facebook или Twitter. Используйте OpenID, если ваши пользователи - это шейные борода, у которых есть свои собственные поставщики OpenID, потому что они "не хотят, чтобы кто-то еще владел их личностью".

Источник