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

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

Оригинальный 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 маркер, подписанный поставщиком идентичности. Приложение может использовать id_tokenдля установки локального сеанса на основе утверждений, включенных в токен JWT, но id_token не может использоваться для дальнейшего запроса других служб, такие вызовы сторонним службам все равно должны использоватьaccess_token, Тогда вы можете рассматривать OpenID Connect как гибрид между SAML2 (подписанный токен) и OAuth2 (токен доступа), поскольку OpenID Connect включает в себя и то, и другое.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник