SAML против федеративного входа с OAuth

Ответ 1

Они решают разные проблемы.

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

OAuth больше о делегировании доступа к чему-либо. Вы в основном позволяете кому-то "действовать" как вы. Его наиболее часто используется для предоставления доступа api, который может что-то сделать от вашего имени.

Это две совершенно разные вещи.

Некоторые примеры, которые могут помочь.

OAuth подумает о твиттере. Допустим, вы используете Живую ленту Google и Twitter, и хотите написать приложение, чтобы иметь возможность синхронизировать два. В основном вы можете установить доверие между вашим приложением и твиттером. В первый раз, когда вы подключаете приложение к твиттеру, вы делаете классическое приглашение для входа в твиттер, а затем появляется окно с подтверждением и спрашивает: "Хотели бы вы предоставить доступ к" вашему имени приложения "?" после того, как вы нажмете "да", доверие было установлено, и теперь ваше приложение может действовать как вы в Twitter. Он может читать ваши сообщения, а также создавать новые.

SAML - Для SAML подумайте о каком-то "соглашении" между двумя несвязанными системами членства. В нашем случае мы можем использовать US Airways и Hertz. Нет общего набора учетных данных, которые могут переносить вас с одного сайта на другой, но позволяет Герцу хотеть предложить "сделку" с US Airways. (Конечно, я знаю, что это крайний пример, но голый со мной). После покупки рейса они будут предлагать бесплатный прокат автомобилей своим членам-членам. US Airways и Hertz установили какую-то форму доверия и каким-то образом идентифицировали пользователя. В нашем случае наш "федеративный идентификатор" будет адресом электронной почты, и это будет один из способов доверия Герца, которому доверяет, что поставщик удостоверений авиакомпании Airways предоставит токен, который является точным и безопасным способом. После бронирования рейса поставщик авиалиний US Airways генерирует токен и заполняет, как они аутентифицировали пользователя, а также "атрибуты" о человеке в нашем случае самым важным атрибутом будет его статус в US Airways. После того, как токен был заполнен, он передает его через какой-либо тип ссылки или закодирован в URL-адресе, и как только мы доберемся до Hertz, он посмотрит на токен, проверит его и теперь может разрешить бесплатный прокат автомобилей.

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

В качестве альтернативы, если вы не заботитесь о авторизации, вы можете почти утверждать, что утверждение аутентификации через SAML и OpenID.

Ответ 2

Посмотрите это простое объяснение:

Многие люди смущены различиями между SAML, OpenID и OAuth, но на самом деле очень просто. Хотя есть некоторые перекрытие, вот очень простой способ провести различие между три.

OpenID - единый вход для потребителей

SAML - единый вход для корпоративных пользователей

OAuth - авторизация API между приложениями

Для людей, устраивающих шаблоны проектирования OO, я думаю, что есть хорошее следствие шаблонов обертки. Подумайте о моделях Facade, Decorator и Proxy. В сущности, это все равно, они просто обертки... Разница заключается в намерении каждого шаблона.

Аналогично, SAML, OAuth и OpenID способствуют разным намерениям с помощью общего основного механизма, который перенаправляется на поставщика услуг/удостоверения личности для некоторого частного взаимодействия, за которым следует перенаправление к исходной третьей стороне приложение.

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

Для самого вопроса в корпоративном контексте SAML звучит более подходящим, чем OAuth для SSO. Я бы поспорил, если вы посмотрите на сторонние приложения, которые хотите интегрировать с корпоративными идентификаторами, вы обнаружите, что они уже разработаны для интеграции с SAML/LDAP/Radius и т.д. IMO OAuth более подходит для взаимодействия с Интернетом между приложениями или, возможно, приложениями, включающими сервис-ориентированную архитектуру в большой корпоративной среде.

Правила авторизации могут быть указаны в корпоративной среде и другими способами. LDAP - общий инструмент для этого. Широко распространенный подход к организации групп пользователей и привязка привилегий приложений к членству в группах. Именно так, LDAP также может использоваться для аутентификации. Active Directory - отличный пример, хотя я предпочитаю OpenLDAP.

Ответ 3

SAML имеет множество "профилей", чтобы выбрать, чтобы другие пользователи могли "войти" на ваш сайт. SAML-P или SAML Passive очень распространены и довольно просты в настройке. WS-Trust аналогичен, и он также позволяет создавать федерации среди веб-сайтов.

OAuth предназначен для авторизации. Вы можете прочитать здесь:

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

Ответ 4

Они обрабатывают тонкий вариант использования

• SAML - совместное использование учетных данных (например, единого входа) пользователя различным поставщикам услуг (например, веб-службам или веб-службам).
• OAuth - Пользователь, делегирующий приложение для доступа к ресурсу от имени своего

Ответ 5

SAML предназначен для аутентификации - в основном используется в сценарии Single Sign On. OAuth предназначен для авторизации представлений ресурсов.

JSON Web Token (JWT) является альтернативой для XML-токенов SAML. JWT может использоваться с OAuth

Хорошая ссылка SAML vs. OAuth: какой я должен использовать?