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

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

4 ответов


оригинальный OpenID 2.0 против SAML

это два разных протоколов аутентификации и они отличаются на техническом уровне.

на расстоянии различия начинаются, когда пользователи инициируют аутентификацию. С OpenID логин пользователя обычно является HTTP-адресом ресурса, который отвечает за аутентификацию. С другой стороны, SAML основан на явном доверии между вашим сайтом и поставщиком удостоверений, поэтому довольно редко принимают учетные данные с неизвестного места.

идентификаторы OpenID легко обойти сеть. В качестве разработчика вы можете просто принимать пользователей от разных поставщиков OpenID. С другой стороны, поставщик SAML обычно должен быть закодирован заранее, и вы объединяете свое приложение только с выбранными поставщиками удостоверений. Можно сузить список принятых поставщиков удостоверений OpenID, но я думаю, что это будет против общей концепции OpenID.

С OpenID вы принимаете идентификаторы поступают с произвольных серверов. Кто-то утверждает, что http://someopenid.provider.com/john.smith. Как вы собираетесь сопоставить это с пользователем в своей базе данных? Каким-то образом, например, сохраняя эту информацию с новой учетной записью и распознавая это, когда пользователь снова посещает ваш сайт. Обратите внимание, что любой другой информации о пользователе (включая его имя или адрес электронной почты) нельзя доверять!

С другой стороны, если существует явное доверие между вашим приложением и поставщиком SAML Id, вы можете получить полную информацию о пользователе, включая имя и адрес электронной почты, и этой информации можно доверять, только из-за доверительного отношения. Это означает, что вы склонны полагать, что поставщик Id каким-то образом проверил всю информацию, и вы можете доверять ей на уровне приложения. Если пользователи приходят с токенами SAML, выданными неизвестным поставщиком, ваше приложение просто отказывается от аутентификации.

OpenID Connect vs 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, выданные поставщиком удостоверений, подписываются XMLs, приложение проверяет саму подпись и сертификат, который она представляет. Сведения о пользователе включены в маркер SAML, среди прочих сведений.

  • OAuth2 строит отношение доверия на прямом вызове HTTPs из приложения к идентификатору. Запрос содержит маркер доступа (полученный приложение во время потока протокола) и ответ содержит информацию о пользователе.

  • OpenID Connect дополнительно расширяет это, чтобы можно было получить идентификатор без этот дополнительный шаг, включающий вызов из приложения к поставщику удостоверений. Идея основана на том, что провайдеры OpenID Connect фактически выдают два жетоны,access_token, тот же самый OAuth2.0 вопросов и новый, id_token что это JWT в маркер подпись провайдером идентификации. Приложение может использовать маркер id для создания локального сеанса на основе утверждений, включенных в маркер JWT, но маркер id нельзя использовать для дальнейшего запроса других служб такие вызовы сторонних служб должны по-прежнему использовать маркер доступа. Вы можете думать о OpenID Connect тогда как гибрид между SAML2 (подписанный токен) и OAuth2 (токен доступа), как OpenID Connect просто предполагает как.


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

  1. SAML2 поддерживает единый выход-но OpenID не
  2. поставщики услуг SAML2 связаны с поставщиками удостоверений SAML2, но проверяющие стороны OpenID не связаны с поставщиками OpenID. OpenID имеет протокол обнаружения, который динамически обнаруживает соответствующего поставщика OpenID, как только OpenID задан. SAML, который имеет протокол обнаружения на основе службы обнаружения поставщика удостоверений Протокол.
  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 и другими стандартами auth (inc. ВКонтакте) заключается в том, что

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

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

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

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

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

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

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

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

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

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