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

В чем разница между SAML и федеративным входом через OAuth? Какое решение имеет больше смысла, если компания хочет использовать стороннее веб-приложение, но при этом хочет единого входа и быть органом аутентификации?

Они решают разные задачи.

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, OpenID и OAuth, но на самом деле это очень просто. Хотя есть некоторое совпадение, вот очень простой способ различить три.

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

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

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

Для тех, кто знаком с шаблонами объектно-ориентированного проектирования, я думаю, что есть хорошее следствие шаблонов-оберток . Подумайте о паттернах фасадов , декораторов и прокси . По сути это все равно, они просто фантики ... Разница заключается в намерении каждого шаблона .

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

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

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

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

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

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

Нашел здесь хорошую статью

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, но это не совсем то же самое. Я нашел этот пост в блоге действительно полезным с точки зрения того, что на самом деле означает федерация.