Какая разница между SAML и объединенным логином с OAuth? Какое решение имеет смысл, если компания хочет использовать сторонний webapp, но также хочет иметь единый вход и быть авторизационным?
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 предназначен для авторизации. Вы можете прочитать здесь:
Ответ 4
Они обрабатывают тонкий вариант использования
- SAML - совместное использование учетных данных (например, единого входа) пользователя различным поставщикам услуг (например, веб-службам или веб-службам).
- OAuth - Пользователь, делегирующий приложение для доступа к ресурсу от имени своего
Ответ 5
SAML предназначен для аутентификации - в основном используется в сценарии Single Sign On. OAuth предназначен для авторизации представлений ресурсов.
JSON Web Token (JWT) является альтернативой для XML-токенов SAML. JWT может использоваться с OAuth
Хорошая ссылка SAML vs. OAuth: какой я должен использовать?