Они решают разные задачи.
SAML - это набор стандартов, которые были определены для обмена информацией о том, кто такой пользователь, каковы его атрибуты, и дают вам способ предоставить / запретить доступ к чему-либо или даже запросить аутентификацию.
OAuth - это больше о делегировании доступа к чему-либо. По сути, вы позволяете кому-то «действовать» как вы. Чаще всего используется для предоставления доступа к API, который может что-то делать от вашего имени.
Это две совершенно разные вещи.
Некоторые примеры, которые могут помочь.
OAuth представляет собой твиттер. Допустим, вы используете Живую ленту Google и Twitter и хотите написать приложение, чтобы иметь возможность поддерживать их синхронизацию. По сути, вы можете установить доверительные отношения между вашим приложением и твиттером. В первый раз, когда вы пытаетесь связать приложение с твиттером, вы делаете классический запрос на вход в твиттер, а затем появляется окно подтверждения и спрашивает: «Хотите ли вы предоставить доступ к« имени вашего приложения »?» как только вы нажмете «да», доверие будет установлено, и теперь ваше приложение может действовать в Твиттере, как вы. Он может читать ваши сообщения, а также создавать новые.
SAML - для SAML подумайте о каком-то «соглашении» между двумя несвязанными системами членства. В нашем случае мы можем использовать US Airways и Hertz. Не существует общего набора учетных данных, который мог бы перенаправить вас с одного сайта на другой, но допустим, Hertz хочет предложить «сделку» с US Airways. (Конечно, я знаю, что это крайний пример, но терпите меня). После покупки рейса они предложат членам-председателям бесплатную аренду автомобиля. US Airways и Hertz установят некоторую форму доверия и способ идентификации пользователя. В нашем случае нашим «федеративным идентификатором» будет адрес электронной почты, и это будет односторонний набор доверия, которому Hertz доверяет, что поставщик удостоверений US Airways доставит точный и безопасный токен. После бронирования рейса провайдер идентификации US Airways сгенерирует токен и укажет, как они аутентифицировали пользователя, а также «атрибуты» человека, в нашем случае наиболее важным атрибутом будет его уровень статуса в US Airways. После того, как токен был заполнен, он передает его через какой-либо тип ссылки или закодирован в URL-адресе, и как только мы добираемся до Hertz, он просматривает токен, проверяет его и теперь может предоставить бесплатную аренду автомобиля.
Проблема с этим примером SAML в том, что это только один специализированный вариант использования из многих. SAML - это стандарт, и существует слишком много способов его реализации.
В качестве альтернативы, если вас не волнует авторизация, вы можете почти возразить, утверждая аутентификацию через SAML и OpenID .
Взгляните на это простое объяснение, приведенное здесь:
Для тех, кто знаком с шаблонами объектно-ориентированного проектирования, я думаю, что есть хорошее следствие шаблонов-оберток . Подумайте о паттернах фасадов , декораторов и прокси . По сути это все равно, они просто фантики ... Разница заключается в намерении каждого шаблона .
Аналогичным образом, SAML, OAuth и OpenID способствуют различным намерениям с помощью общего базового механизма , который представляет собой перенаправление поставщику услуг / органу идентификации для некоторого частного взаимодействия с последующим перенаправлением в исходное стороннее приложение.
Посмотрев в сети, вы обнаружите, что возможности протоколов совпадают. Аутентификация через OAuth вполне разумна. SSO через OAuth может не иметь большого смысла, поскольку SAML и OpenID специально предназначены для федеративной идентификации.
Что касается самого вопроса, в корпоративном контексте SAML звучит более уместно, чем OAuth для единого входа . Готов поспорить, если вы посмотрите на сторонние приложения, которые хотите интегрировать со своей корпоративной идентификацией, вы обнаружите, что они уже разработаны для интеграции с SAML / LDAP / Radius и т. Д. IMO OAuth больше подходит для взаимодействия с Интернетом. между приложениями или, возможно, приложениями, составляющими сервис-ориентированную архитектуру в большой корпоративной среде.
Правила авторизации могут быть указаны в корпоративной среде и другими способами. LDAP - распространенный инструмент для этого. Организация пользователей в группы и связывание прав приложений с членством в группах - широко распространенный подход. Так уж получилось, что LDAP тоже можно использовать для аутентификации. Active Directory - отличный пример, хотя я предпочитаю OpenLDAP.
источник
Они обрабатывают тонкий вариант использования
источник
Нашел здесь хорошую статью
SAML (язык разметки утверждения безопасности) - это набор стандартов для достижения единого входа (SSO), федерации и управления идентификацией.
Пример . Пользователь (принципал) аутентифицируется на веб-сайте бронирования авиабилетов AirFlyer (поставщик удостоверений), на котором SSO настроен через SAML, на веб-сайте бронирования рейсов Shuttler (поставщик услуг). После аутентификации на Flyer пользователь может бронировать шаттлы на Shuttler без аутентификации.
OAuth (Open Authorization) - стандарт авторизации ресурсов. Он не занимается аутентификацией.
Пример : мобильное приложение для обмена фотографиями (потребитель OAuth), которое позволяет пользователям импортировать фотографии из своей учетной записи Instagram (поставщик OAuth), которое отправляет временный токен доступа или ключ в приложение для обмена фотографиями, срок действия которого истекает через несколько часов.
источник
SAML имеет множество «профилей» на выбор, позволяющих другим пользователям «входить» на ваш сайт. SAML-P или SAML Passive очень распространены и довольно просты в настройке. WS-Trust аналогичен, и он также позволяет объединение веб-сайтов.
OAuth предназначен для авторизации. Вы можете прочитать больше здесь:
В чем разница между OpenID и OAuth?
источник
SAMLпредназначен для аутентификации - в основном используется в сценарии единого входа .OAuthпредназначен для авторизации представлений ресурсов.Веб-токен JSON (JWT) является альтернативой для токенов SAML XML. JWT можно использовать с OAuth
Хороший пример - SAML или OAuth: что мне использовать?
источник
Термин «федерация» на самом деле означает идентификацию соединения между системами. Это связано с SSO, но это не совсем то же самое. Я нашел этот пост в блоге действительно полезным с точки зрения того, что на самом деле означает федерация.
источник