SAML vs об'єднаний логін із OAuth
Відповіді:
Вони вирішують різні проблеми.
SAML - це набір стандартів, визначених для обміну інформацією про те, хто є користувачем, яким є його набір атрибутів, і дати вам спосіб надати / заборонити доступ до чогось або навіть запитати автентифікацію.
OAuth більше стосується делегування доступу до чогось. Ви в основному дозволяєте комусь «діяти» як ви. Його найчастіше використовують для надання доступу до програм, які можуть зробити щось від вашого імені.
Це дві абсолютно різні речі.
Деякі приклади, які можуть допомогти.
OAuth подумайте про щебетання. Скажімо, ви використовуєте Google Buzz та Twitter, і ви хочете написати додаток, щоб вони могли зберігати синхронізацію. Ви в основному можете встановити довіру між вашим додатком та щебетачем. Перший раз, коли ви перейдете на зв'язок програми з твіттером, ви робите класичну підказку для входу в твіттер, а потім з'являється вікно підтвердження і запитує "Чи бажаєте ви надати доступ до" вашого імені програми "?" як тільки ви натиснете "так", довіра була встановлена, і тепер ваш додаток може діяти як ви в Twitter. Він може читати ваші публікації, а також створювати нові.
SAML - Для SAML подумайте про якийсь тип "угоди" між двома незв'язаними системами членства. У нашому випадку ми можемо використовувати US Airways та 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 між додатками
Для людей, які зручні з моделями дизайну OO, я думаю, що тут є приємна відповідь для моделей обгортки . Придумайте моделі фасадів , декораторів та проксі . По суті це все одно, вони просто обгортки ... Різниця полягає у намірі кожного зразка .
Так само SAML, OAuth та OpenID сприяють різним намірам через загальний базовий механізм , який є перенаправленням до постачальника послуг / органу ідентичності для певної приватної взаємодії з подальшим перенаправленням на вихідний додаток третьої сторони.
Озирнувшись по мережі, ви побачите перекриття між можливостями протоколів. Аутентифікація через OAuth цілком розумна. SSO над OAuth може не мати великого сенсу, хоча як SAML і OpenID спеціально орієнтовані на федеративну ідентичність.
Що стосується самого питання, у корпоративному контексті SAML для SSO звучить більш доцільно, ніж OAuth . Я ставлюся під заклад, якщо ви подивитеся на додатки сторонніх розробників, які ви хочете інтегрувати з корпоративними ідентичностями, ви побачите, що вони вже розроблені для інтеграції з SAML / LDAP / Radius і т.д. між додатками або, можливо, додатками, що містять сервісно-орієнтовану архітектуру у великих корпоративних умовах.
Правила авторизації можуть бути визначені в корпоративному середовищі і іншими способами. LDAP є загальним інструментом для цього. Організація користувачів у групи та асоціація привілеїв програми проти членства в групі - це широко поширений підхід. Так буває, LDAP може використовуватися і для аутентифікації. Active Directory - прекрасний приклад, хоча я віддаю перевагу OpenLDAP.
Знайдено Гарна стаття тут
SAML (Мова затвердження безпеки) - це набір стандартів для досягнення єдиного входу (SSO), Федерації та управління особами.
Приклад : Користувач (основний) засвідчує автентифікацію на веб-сайті бронювання авіарейсів, AirFlyer (постачальник ідентифікаційних даних), який має SSO, налаштований через SAML, із веб-сайтом бронювання шатлів, Shuttler (постачальник послуг). Після автентифікації на Flyer користувач може забронювати маршрутки на Shuttler, не вимагаючи аутентифікації
OAuth (Open Authorization) - стандарт для авторизації ресурсів. Це не стосується автентифікації.
Приклад : Мобільний додаток для обміну фотографіями (споживач OAuth), який дозволяє користувачам імпортувати фотографії зі свого акаунта в Instagram (постачальник OAuth), який надсилає тимчасовий маркер доступу або ключ до програми для обміну фотографіями, який закінчується через кілька годин.
SAML має різноманітні "профілі" на вибір, щоб інші користувачі могли "увійти" на ваш сайт. SAML-P або SAML Pasive дуже поширений і досить простий у налаштуванні. WS-Trust схожий і він також дозволяє федерацію серед веб-сайтів.
OAuth призначений для авторизації. Більше ви можете прочитати тут:
SAMLпризначений для аутентифікації - в основному використовується в сценарії Single Sign On . OAuthпризначений для авторизації представлення ресурсів.
JSON Web Token (JWT) - це альтернатива для SAML XML-токерів. JWT можна використовувати з OAuth
Хорошим посиланням є SAML проти OAuth: який я повинен використовувати?
Терміни федерація дійсно означає ідентичність з'єднання між системами. Це стосується SSO, але вони не зовсім однакові. Я знайшов цю публікацію в блозі дуже корисною з точки зору того, що насправді означає федерація.