Чим відрізняється OpenID від SAML?

Чим відрізняється OpenID від SAML?

Оригінальний OpenID 2.0 проти SAML

Вони є двома різними протоколами аутентифікації і вони відрізняються на технічному рівні.

Здалеку відмінності починаються, коли користувачі ініціюють аутентифікацію. За допомогою OpenID вхід користувача, як правило, є HTTP-адресою ресурсу, який відповідає за аутентифікацію. З іншого боку, SAML базується на явній довірі між вашим сайтом та постачальником послуг, тому досить рідко приймаються дані з невідомого сайту.

Ідентичності OpenID легко обійти в мережі. Як розробник, ви можете просто прийняти користувачів, що надходять від дуже різних OpenID-провайдерів. З іншого боку, постачальника SAML зазвичай потрібно кодувати заздалегідь, і ви об'єднуєте свою заявку лише з обраними постачальниками посвідчень. Перелік прийнятих постачальників ідентичності OpenID можливо звузити, але я думаю, що це було б проти загальної концепції OpenID.

З OpenID ви приймаєте ідентичності, що надходять з довільних серверів. Хтось стверджує, що є http://someopenid.provider.com/john.smith. Як ви збираєтеся відповідати цьому користувачеві у вашій базі даних? Якось, наприклад, зберігаючи цю інформацію в новому обліковому записі та розпізнаючи її, коли користувач знову відвідує ваш сайт. Зауважте, що будь-якій іншій інформації про користувача (включаючи його ім’я чи електронну пошту) не можна довіряти!

З іншого боку, якщо явна довіра між вашою заявою та провайдером SAML Id, ви можете отримати повну інформацію про користувача, включаючи ім’я та електронну пошту, і цій інформації можна довіряти саме через довіру. Це означає, що ви схильні вважати, що постачальник ідентифікаторів якимось чином перевірив всю інформацію, і ви можете їй довіряти на рівні програми. Якщо користувачі отримують токени SAML, видані невідомим постачальником, ваша програма просто відмовляється від автентифікації.

OpenID Connect проти SAML

(додано розділ 07-2017, розгорнуто 08-2018)

Ця відповідь датується 2011 роком, і на той час OpenID виступав за OpenID 2.0 . Пізніше, десь у 2012 році, був опублікований OAuth2.0 , а в 2014 році OpenID Connect (більш детальна хронологія тут ).

Для всіх, хто читає це сьогодні - OpenID Connect не є тим самим OpenID, на який посилається оригінальна відповідь , скоріше це набір розширень до OAuth2.0.

Хоча ця відповідь може пролити трохи світла з концептуальної точки зору, дуже стислий варіант для тих, хто приходить з фоном OAuth2.0, полягає в тому, що OpenID Connect насправді є OAuth2.0, але додає стандартний спосіб запиту інформації про користувача після маркера доступу доступний.

Посилаючись на початкове запитання - в чому головна відмінність OpenID Connect (OAuth2.0) від SAML - це те, як будується довірче відношення між програмою та постачальником ідентифікаторів:

• SAML будує довірче відношення на цифровому підписі, токени SAML, видані постачальником послуг, підписують XML, додаток підтверджує сам підпис та сертифікат, який він представляє. Інформація про користувача включається в маркер SAML, серед іншого.

• OAuth2 будує довірче відношення на прямому HTTP-виклику від програми до ідентичності. Запит містить маркер доступу (отриманий програмою під час потоку протоколу), а відповідь містить інформацію про користувача.

• OpenID Connect додатково розширює це, щоб можна було отримати особу без цього додаткового кроку, що включає виклик програми від постачальника ідентифікації. Ідея заснована на тому, що постачальники OpenID Connect насправді випускають два жетони, той access_tokenсамий, один випуск OAuth2.0 і новий, id_tokenякий є маркером JWT , підписаний постачальником ідентичності. Додаток може використовувати id_tokenдля встановлення локальної сесії на основі претензій, включених до маркера JWT, але id_token не може бути використаний для подальшого запиту інших служб, такі виклики до сторонніх служб все одно повинні використовуватиaccess_token. Ви можете думати про OpenID Connect тоді як гібрид між SAML2 (підписаний маркер) та OAuth2 (маркер доступу), оскільки OpenID Connect просто включає обидва.

OpenID та SAML2 базуються на одній концепції об'єднаної ідентичності. Нижче наведено деякі відмінності між ними.

1. SAML2 підтримує єдиний вихід, але OpenID цього не робить
2. Постачальники послуг SAML2 поєднуються з постачальниками ідентифікаторів SAML2, але сторони, які покладаються на OpenID, не поєднуються з постачальниками OpenID. OpenID має протокол виявлення, який динамічно виявляє відповідного постачальника OpenID, як тільки буде відкрито OpenID. SAML має протокол виявлення на основі протоколу служби виявлення постачальника ідентичності.
3. З SAML2 користувач з'єднується з SAML2 IdP - ваш ідентифікатор SAML2 дійсний лише для SAML2 IdP, який його видав. Але з OpenID ви володієте своїм ідентифікатором, і ви можете зіставити його будь-якому постачальнику OpenID, який хочете.
4. SAML2 має різні прив’язки, тоді як єдиним зв'язуючим OpenID є HTTP
5. SAML2 може бути ініційованим постачальником послуг (SP) або ініційованим постачальником послуг (IdP). Але OpenID завжди ініційований SP.
6. SAML 2 заснований на XML, тоді як OpenID не є.
7. Більшість додатків, розроблених за останні 3 роки, підтримували лише OpenID Connect.
8. 92% запитів на аутентифікацію 8B +, які Microsoft Azure AD передав у травні 2018 року, надходили із програм із підтримкою OpenID Connect.

Відкладаючи технічні деталі в сторону, запізнюючись на вечірку, я розумію, що найбільша різниця між SAML та іншими аутентичними стандартами (включаючи OpenID) полягає в тому, що

SAML вимагає від постачальника даних (IDP) та постачальника послуг (SP), щоб вони знали один одного заздалегідь, попередньо налаштовані , статична автентифікація та авторизація. OpenId (+ Connect) не має такої вимоги.

Це важливо для ВПО, які хочуть повністю контролювати, хто отримує доступ до даних. Частина стандарту полягає в налаштуванні того, що надається конкретним SP.

Наприклад, банк може не бажати, щоб його користувачі отримували доступ до будь-яких послуг, крім деяких заздалегідь визначених (через положення чи інші суворі правила безпеки).

Це не означає, що ID ID OpenId не може застосувати таке обмеження. Реалізатор OpenID може контролювати доступ, але це не мета OpenID.

За винятком попередньо визначених, суворих, статичних, різниця в контролі доступу, концептуально (не технічно), OpenID Connect та SAML схожі.

Підсумок, якщо ви є партнером, ви повинні підтримувати те, що вимагають ваші клієнти:

1. Якщо ваш клієнт - це індивідуальний клієнт кінцевого споживача (використовуючи, наприклад, їх google id), забудьте про SAML. Використовуйте OpenID Connect.
2. Якщо ваш клієнт - це банк, який бажає, щоб його працівники використовували вашу послугу та експортували лише статичний список даних, які вони надаватимуть вашій службі, банк, ймовірно, захоче, щоб ви підтримували SAML. У банку може бути реалізація OpenID з обмеженням клієнта, який стане вашим щасливим днем ​​:)

І SAML, і OpenID можуть виступати провайдером ідентифікації (скорочено IdP), тобто децентралізованим протоколом аутентифікації (ідентифікація єдиного входу).

S ecurity ssertion М arkup L anguage ( SAML ) являє собою набір профілів для обміну даними аутентифікації і авторизації між доменами безпеки. У моделі домену SAML постачальник ідентифікаційних даних є спеціальним типом повноважень аутентифікації. Зокрема, постачальник ідентичності SAML - це системний об'єкт, який видає підтвердження автентифікації спільно з профілем SSO SAML. Надійна сторона, яка споживає ці твердження аутентифікації, називається постачальником послуг SAML. Джерело

Виведення пера ID С кий підключити ( РСІН ) являє собою шар аутентифікації поверх OAuth 2.0, рамка авторизації. Стандарт контролюється Фондом OpenID. OAuth призначений для протоколу авторизації, а не протоколу аутентифікації та OpenID, спеціально розробленого як протокол аутентифікації. OIDC використовує прості веб-маркери JSON (JWT), їх легше споживати через JavaScript.

Сценарій використання випадку:

Використовуйте OAuth, якщо ваші користувачі, можливо, просто захочуть увійти за допомогою Facebook або Twitter. Використовуйте OpenID, якщо ваші користувачі мають шиї, які працюють з власними постачальниками OpenID, оскільки вони "не хочуть, щоб хтось інший володів своєю особою".

Джерело