Они решают разные проблемы.
SAML - это набор стандартов, которые были определены для обмена информацией о том, кто пользователь, каковы его наборы атрибутов, и дают вам возможность предоставить / запретить доступ к чему-либо или даже запрос аутентификации.
OAuth больше о делегировании доступа к чему-либо. Вы в основном позволяете кому-то «действовать» как вы. Чаще всего он используется для предоставления доступа к API, которые могут что-то делать от вашего имени.
Это две совершенно разные вещи.
Некоторые примеры, которые могут помочь.
О, подумай о твиттере. Допустим, вы используете Google Buzz и Twitter, и вы хотите написать приложение, которое позволит синхронизировать их. Вы можете установить доверие между вашим приложением и Twitter. Когда вы впервые связываете приложение с твиттером, вы делаете классический запрос на вход в твиттер, а затем появляется окно подтверждения с вопросом «Хотите ли вы предоставить доступ к« имени вашего приложения »?» как только вы нажмете «да», доверие будет установлено, и теперь ваше приложение может действовать как вы в Twitter. Он может читать ваши сообщения, а также создавать новые.
SAML - для SAML подумайте о некоем «соглашении» между двумя несвязанными системами членства. В нашем случае мы можем использовать US Airways и Hertz. Не существует общего набора учетных данных, которые могут перенести вас с одного сайта на другой, но предположим, что Hertz хочет предложить «сделку» US Airways. (Конечно, я знаю, что это крайний пример, но потерпите меня). После покупки рейса они предложат бесплатный прокат автомобиля своим членам. US Airways и Hertz установили бы некоторую форму доверия и способ идентификации пользователя. В нашем случае нашим «федеративным идентификатором» будет адрес электронной почты, и это будет один из способов доверия, которым Герц доверяет, чтобы поставщик идентификационных данных US Airways предоставил токен точным и безопасным образом. После бронирования рейса поставщик идентификационных данных US Airways сгенерирует токен и укажет способ аутентификации пользователя, а также «атрибуты» о человеке, в нашем случае наиболее важным атрибутом будет его уровень статуса в US Airways. После того, как токен заполнен, он передает его через какой-либо тип ссылки или кодируется в URL-адресе, а когда мы добираемся до Герца, он смотрит на токен, проверяет его и теперь может предоставить бесплатный прокатный автомобиль.
Проблема с этим примером SAML в том, что это только один специализированный вариант из многих. SAML является стандартом, и его можно реализовать почти слишком многими способами.
В качестве альтернативы, если вас не волнует авторизация, вы можете почти утверждать, что подтверждение аутентификации через SAML и OpenID .