Яка різниця між OpenID та OAuth?

Я справді намагаюся зрозуміти різницю між OpenID та OAuth? Може, це дві абсолютно окремі речі?

OpenID - це аутентифікація (тобто доказ того, хто ви є), OAuth - це авторизація (тобто, щоб надати доступ до функціональності / даних / тощо) без необхідності мати справу з оригінальною автентифікацією).

OAuth можна використовувати на зовнішніх веб-сайтах партнерів, щоб дозволити доступ до захищених даних без необхідності повторної аутентифікації користувача.

Повідомлення в блозі " OpenID проти OAuth з точки зору користувача " має просте порівняння двох з точки зору користувача, і " OAuth-OpenID: ти гавкаєш неправильне дерево, якщо ти думаєш, що вони однакова річ " має більше інформації про це.

Є три способи порівняння OAuth та OpenID:

1. Цілі

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

OAuth створений для того, щоб скасувати необхідність користувачів ділитися своїми паролями сторонніми програмами . Це фактично почалося як спосіб вирішити проблему з OpenID: якщо ви підтримуєте OpenID на своєму сайті, ви не можете використовувати облікові дані HTTP Basic (ім’я користувача та пароль) для надання API, оскільки користувачі не мають пароля на вашому сайті.

Проблема полягає в тому, що розділення OpenID для аутентифікації та OAuth для авторизації полягає в тому, що обидва протоколи можуть виконувати багато одних і тих же речей. Кожен з них надає різний набір функцій, які бажані різними реалізаціями, але, по суті, вони досить взаємозамінні. По суті, обидва протоколи є методом підтвердження тверджень (OpenID обмежений твердженням "це я є хто", тоді як OAuth надає "маркер доступу", який можна обміняти на будь-яке підтримуване твердження через API).

2. Особливості

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

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

OAuth - найважливіша особливість OAuth - це маркер доступу, який забезпечує тривалий спосіб отримання додаткових запитів. На відміну від OpenID, OAuth не закінчується автентифікацією, але надає маркер доступу для отримання доступу до додаткових ресурсів, наданих тим самим стороннім сервісом. Однак, оскільки OAuth не підтримує відкриття, він вимагає попереднього вибору та жорсткого кодування постачальників, яких ви вирішили використовувати. Користувач, який відвідує ваш сайт, не може використовувати жоден ідентифікатор, лише попередньо обраний вами. Крім того, OAuth не має поняття ідентичності, тому використання його для входу означає або додати користувальницький параметр (як це робиться у Twitter), або здійснити інший виклик API, щоб отримати користувача, який наразі "увійшов".

3. Технічні втілення

Два протоколи мають спільну архітектуру при використанні перенаправлення для отримання авторизації користувача. У OAuth користувач надає доступ до своїх захищених ресурсів та у OpenID, до своєї ідентичності. Але це все, чим вони діляться.

Кожен протокол має різний спосіб обчислення підпису, який використовується для перевірки достовірності запиту чи відповіді, і кожен має різні вимоги до реєстрації.

OpenID - це (головним чином) для ідентифікації / автентифікації, так що stackoverflow.comзнаю, що я є власником chris.boyle.name(або деінде), і тому я, мабуть, та сама людина, яка chris.boyle.nameвчора була власницею та отримала певні бали репутації.

OAuth призначений для дозволу на вчинення дій від вашого імені, щоб stackoverflow.com(або де завгодно) можна було запитувати дозвіл на, скажімо, щебетання від вашого імені автоматично, не знаючи вашого пароля Twitter.

Багато людей все ще відвідують це, ось ось дуже проста схема, щоб пояснити це

Люб’язно надана Вікіпедія

OAuth

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

тобто Flickr використовує OAuth, щоб дозволити стороннім службам розміщувати та редагувати зображення особи від свого імені, без того, щоб вони видавали ім’я користувача та пароль мерехтіння.

OpenID

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

тобто один показує свій паспорт в аеропорту для підтвердження (або підтвердження) того, хто є ім'ям особи в квитку, який вони використовують, це вони.

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

• OpenID - це відкритий стандарт і децентралізований протокол аутентифікації, який контролюється OpenID Foundation.
• OAuth - це відкритий стандарт для делегування доступу.
• OpenID Connect (OIDC) Поєднує в собі функції OpenID та OAuth, тобто робить як аутентифікацію, так і авторизацію.

OpenID має форму унікального URI, яким керує деякий "постачальник OpenID", тобто постачальник ідентифікаційних даних (idP).

OAuth можна використовувати спільно з XACML, коли OAuth використовується для згоди власності та делегування доступу, тоді як XACML використовується для визначення політики авторизації.

OIDC використовує прості веб-маркери JSON (JWT), які ви можете отримати, використовуючи потоки, що відповідають специфікаціям OAuth 2.0 . OAuth безпосередньо пов'язаний з OIDC, оскільки OIDC - це рівень аутентифікації, побудований поверх OAuth 2.0 .

Наприклад , якщо ви вирішили ввійти в Auth0 за допомогою свого облікового запису Google, тоді ви використовували OIDC . Після успішної аутентифікації з Google та дозволу Auth0 отримати доступ до вашої інформації, Google поверне Auth0 інформацію про користувача та виконану автентифікацію. Ця інформація повертається у веб-токені JSON (JWT). Ви отримаєте маркер доступу та, якщо потрібно, маркер ідентифікатора. Типи токенів : Джерело: OpenID Connect

Аналогія :
Організація використовує ідентифікаційну картку для ідентифікації, і вона містить чіпи, вона зберігає дані про Співробітника, а також Авторизацію, тобто доступ до кампусу / ворота / ODC. Ідентифікаційна картка виступає як OIDC, а Chip - OAuth . більше прикладів та формувати вікі

OpenID та OAuth - кожен протокол, заснований на HTTP, для аутентифікації та / або авторизації. Обидві призначені для того, щоб дозволити користувачам виконувати дії, не надаючи довіреностей для автентифікації або дозволу на замовлення клієнтам або третім сторонам. Хоча вони схожі і є запропоновані стандарти, щоб використовувати їх обидва разом, вони є окремими протоколами.

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

OAuth призначений для делегованого авторизації. Клієнт реєструється у постачальника, який надає маркери авторизації, які він прийме для виконання дій від імені користувача.

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

Я вважаю, що має сенс переглянути це питання, як це також зазначалося в коментарях, введення OpenID Connect, можливо, призвело до ще більше плутанини.

OpenID Connect - це протокол аутентифікації, такий як OpenID 1.0 / 2.0, але він фактично побудований на версії OAuth 2.0, тому ви отримаєте функції авторизації разом із функціями аутентифікації. Різниця між цими двома досить добре пояснена у цій (відносно недавній, але важливій) статті: http://oauth.net/articles/authentication/

Пояснення різниці між OpenID, OAuth, OpenID Connect:

OpenID - це протокол аутентифікації, тоді як OAuth - для авторизації. Аутентифікація полягає в тому, щоб переконатися, що хлопець, з яким ви спілкуєтесь, справді є тим, ким він стверджує, що він є. Авторизація - це вирішення питання, що йому потрібно дозволити.

У OpenID автентифікація делегована: сервер A хоче автентифікувати користувача U, але облікові дані U (наприклад, ім'я та пароль U) надсилаються на інший сервер B, якому A довіряє (принаймні, довіряє автентифікація користувачів). Дійсно, сервер B переконується, що U справді є U, а потім каже A: "нормально, це справжнє U".

В OAuth авторизація делегована: суб'єкт А отримує від об'єкта B "право доступу", яке A може показати серверу S, щоб отримати доступ; Таким чином, B може доставити тимчасові, конкретні ключі доступу до A, не надаючи їм занадто великої потужності. Ви можете уявити сервер OAuth як головного майстра у великому готелі; він дає працівникам ключі, які відкривають двері кімнат, в які вони повинні входити, але кожен ключ обмежений (він не дає доступу до всіх кімнат); крім того, ключі самознищуються через кілька годин.

В якійсь мірі авторизація може бути зловживана деякою псевдоаутентифікацією, виходячи з того, що якщо сутність A отримує від B ключ доступу через OAuth і показує його на сервер S, то сервер S може зробити висновок, що B автентифіковано A перед наданням доступу ключ. Тому деякі користуються OAuth там, де вони повинні використовувати OpenID. Ця схема може бути або не бути освічуючою; але я думаю, що ця псевдоаутентифікація є більш заплутаною, ніж будь-що. OpenID Connect робить саме це: він зловживає OAuth в протоколі аутентифікації. У аналогії готелю: якщо я зіткнувся із заявленим працівником і ця людина показала мені, що у нього є ключ, який відкриває мою кімнату, то я гадаю, що це справжній працівник, виходячи з того, що головний господар не дав би йому ключа що відкриває мою кімнату, якщо його не було.

(джерело)

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

OpenID Connect виконує багато тих самих завдань, що і OpenID 2.0, але робить це таким чином, що є API-інтерфейсом та зручним для використання в домашніх і мобільних додатках. OpenID Connect визначає додаткові механізми для надійного підписання та шифрування. Якщо інтеграція OAuth 1.0a та OpenID 2.0 вимагає розширення, то в OpenID Connect можливості OAuth 2.0 інтегровані з самим протоколом.

(джерело)

Підключення OpenID надасть вам маркер доступу плюс маркер ідентифікатора. Маркер id - це JWT і містить інформацію про автентифікованого користувача. Він підписаний постачальником ідентифікації та може бути прочитаний та перевірений без доступу до постачальника посвідчень особи.

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

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

(джерело)

Google OAuth 2.0

API API OAuth 2.0 Google можна використовувати як для автентифікації, так і для авторизації. Цей документ описує нашу реалізацію OAuth 2.0 для аутентифікації, яка відповідає специфікації OpenID Connect і сертифікована OpenID. Документація, знайдена в розділі Використання OAuth 2.0 для доступу до API API Google, також стосується цієї послуги. Якщо ви хочете вивчити цей протокол в інтерактивному режимі, ми рекомендуємо ігровий майданчик Google OAuth 2.0 .

(джерело)

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

Однозначно буде реалізовано базовий інтерфейс автентифікації для імені користувача / пароля, але визнає, що для все більшої кількості користувачів думка про ще одне ім'я користувача та пароль є стримуючим фактором. Хоча це не зовсім соціальні мережі, я знаю, що дуже великий відсоток потенційних користувачів програми вже має облікові записи facebook або Twitter. Програма не дуже хоче або потребує доступу до інформації про обліковий запис користувача з цих сайтів, вона просто хоче запропонувати зручність не вимагати від користувача налаштування нових облікових даних облікових записів, якщо вони цього не хочуть. З точки зору функціональності, це може здатися дочірнім плакатом для OpenID. Але здається, що ні facebook, ні twitter не є постачальниками OpenID як такими, хоча вони підтримують аутентифікацію OAuth для доступу до даних своїх користувачів.

У всіх статтях, які я читав про ці дві, і про те, як вони відрізняються, поки що я не побачив спостереження Карла Андерсона вище, що "OAuth можна використовувати для аутентифікації, що може розглядатися як безвідмовна авторизація", Я бачив будь-яке явне підтвердження того, що OAuth був досить хорошим для того, що я хотів зробити.

Насправді, коли я пішов опублікувати цю "відповідь", не будучи членом свого часу, я довго і наполегливо дивився внизу цієї сторінки на варіанти ідентифікації себе. Можливість використовувати логін OpenID або отримати його, якщо у мене його не було, але нічого про twitter чи facebook, здавалося, підказує, що OAuth не був адекватним для роботи. Але потім я відкрив ще одне вікно і шукав загальний процес реєстрації для stackoverflow - і ось ось тут є безліч сторонніх варіантів аутентифікації, включаючи facebook та Twitter. Врешті-решт я вирішив використати свій ідентифікатор google (який є OpenID) саме з тієї причини, що я не хотів надавати доступ до мого списку друзів, а ще що-небудь Facebook любить ділитися про своїх користувачів - але принаймні це "

Дійсно було б чудово, якби хтось міг або публікувати інформацію, або вказівники на інформацію про підтримку такого типу множинних налаштувань авторизації третьої частини та про те, як ви маєте справу з користувачами, які відкликають авторизацію або втрачають доступ до свого сайту сторонніх розробників. У мене також складається враження, що моє ім'я користувача тут визначає унікальний обліковий запис stackoverflow, до якого я можу отримати доступ із базовою автентифікацією, якщо хочу налаштувати його, а також отримати доступ до цього ж акаунта через інші сторонні аутентифікатори (наприклад, щоб мене вважали зареєстрованим) увійти в stackoverflow, якщо я ввійшов у будь-який з google, facebook або twitter ...). Оскільки цей сайт робить це, хтось тут, мабуть, має досить гарне розуміння цього питання. :-)

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

OpenID доводить, хто ти є.

OAuth надає доступ до функцій, наданих уповноваженою стороною.

Зараз я працюю на специфікаціях OAuth 2.0 та OpenID. Тож ось моє розуміння: Раніше вони були:

1. OpenID - це власницька реалізація Google, що дозволяє стороннім програмам, наприклад, для газетних веб-сайтів, можна ввійти за допомогою Google і коментувати статтю тощо. Тож по суті, жодного спільного використання пароля на веб-сайті газети. Дозвольте мені викласти тут визначення, такий підхід у підході до підприємств називається Федерацією. У Федерації у вас є сервер, на якому ви здійснюєте автентифікацію та авторизацію (називається IDP, постачальник ідентичності) і, як правило, зберігач облікових даних користувачів. клієнтська програма, у якій ви маєте бізнес, називається SP або постачальником послуг. Якщо ми повернемося до того самого прикладу веб-сайту газети, тоді веб-сайт газети тут є SP, а Google - це IDP. На підприємстві ця проблема була раніше вирішена за допомогою SAML. у той час XML використовувався для управління галуззю програмного забезпечення. Отже, від веб-сервісів до конфігурації, все, що раніше переходило до XML, тому у нас є SAML,

2. OAuth: OAuth бачив, що це поява як стандарт, дивлячись на всі ці види патентованих підходів, і тому ми мали OAuth 1.o як стандарт, але стосувався лише авторизації. Не багато хто помітив, але це почало підбирати. Тоді у нас був OAuth 2.0 у 2012 році. CTO, архітектори дійсно почали звертати увагу, коли світ рухається до хмарних обчислень і з обчислювальними пристроями рухається до мобільних та інших подібних пристроїв. Вигляд OAuth розглядався як вирішення головної проблеми, коли клієнти програмного забезпечення можуть надавати послугу IDP одній компанії та надавати безліч послуг від різних постачальників, таких як salesforce, SAP тощо. Отже, інтеграція тут справді схожа на сценарій федерації, яка є однією великою проблемою, використання SAML є дорогим. тож давайте вивчимо OAuth 2.o. О, пропустив один важливий момент, що за цей час Google відчув, що OAuth насправді не робить '

   а. OAuth 2.o чітко не говорить про те, як відбуватиметься реєстрація клієнтів b. він нічого не згадує про взаємодію між SP (сервер ресурсів) та клієнтською програмою (як, наприклад, сервер Analytics, що надає дані, це сервер ресурсів і програма, що показує, що дані є клієнтом)

Тут вже даються чудові відповіді технічно, я думав дати короткий погляд на еволюцію

OpenId використовує OAuth для роботи з аутентифікацією.

За аналогією це як .NET покладається на Windows API. Ви можете безпосередньо зателефонувати за API Windows, але він настільки широкий, складний і аргумент методів настільки великий, що ви можете легко помилитися / помилки / проблеми з безпекою.

Те саме з OpenId / OAuth. OpenId покладається на OAuth для управління аутентифікацією, але визначаючи конкретний токен (Id_token), цифровий підпис та окремі потоки.

Я хотів би зайнятись певним аспектом цього питання, про який йдеться у цьому коментарі:

OAuth: перш ніж надати доступ до якоїсь функції, потрібно виконати автентифікацію, правда ?. тож OAuth = що OpenId робить + надає доступ до деяких функцій? - Хасан Макаров 21 червня о 1:57

Так і ні. Відповідь тонка, тому потерпіть зі мною.

Коли потік OAuth перенаправляє вас до цільової службі (провайдер OAuth, тобто), то є ймовірність того, що вам необхідно для перевірки справжності цієї служби до того, як маркер буде переданий назад в клієнтському додатку / сервіс. Потім отриманий маркер дозволяє клієнтському додатку робити запити від імені певного користувача.

Зауважте загальність цього останнього речення: конкретно, я писав "від імені даного користувача", а не "від імені вас ". Поширена помилка припускати, що "можливість взаємодіяти з ресурсом, що належить даному користувачеві" означає, що ви та власник цільових ресурсів є одним і тим же ".

Не робіть цієї помилки.

Хоча це правда, що ви автентифікуєтесь у постачальника послуг OAuth (скажімо, за іменем користувача та паролем, або, можливо, сертифікатами клієнта SSL або іншим способом), те, що клієнт отримує натомість, не обов'язково слід сприймати як доказ ідентичності. Прикладом може бути потік, де доступ до ресурсів іншого користувача був делегований вам (і через проксі, клієнт OAuth). Авторизація не означає аутентифікацію.

Для обробки автентифікації ви, швидше за все, захочете заглянути в OpenID Connect, який по суті є ще одним шаром поверх фундаменту, встановленого OAuth 2.0. Ось цитата, яка фіксує (на мій погляд) найпомітніші моменти щодо OpenID Connect (з https://oauth.net/articles/authentication/ ):

OpenID Connect - це відкритий стандарт, опублікований на початку 2014 року, який визначає сумісний спосіб використання OAuth 2.0 для проведення автентифікації користувачів. По суті, це широко опублікований рецепт шоколадної глазурі, який був випробуваний і перевірений широкою кількістю та різноманітністю експертів. Замість того, щоб будувати різний протокол для кожного потенційного постачальника ідентифікаційних даних, програма може говорити про один протокол для стільки постачальників, скільки вони хочуть працювати. Оскільки це відкритий стандарт, OpenID Connect може реалізовувати будь-хто без обмежень чи інтелектуальної власності.

OpenID Connect побудований безпосередньо на OAuth 2.0 і в більшості випадків розгортається прямо разом з (або поверх) інфраструктурою OAuth. OpenID Connect також використовує набір JSON-підпису та шифрування об'єктів (JOSE) специфікацій для перенесення підписаної та зашифрованої інформації в різних місцях. Насправді розгортання OAuth 2.0 з можливостями JOSE - це вже довгий шлях до визначення повністю сумісної системи OpenID Connect, а дельта між ними порівняно мала. Але ця дельта має велике значення, і OpenID Connect вдається уникнути багатьох обговорених вище підводних каменів, додаючи до бази OAuth декілька ключових компонентів: [...]

Далі документ далі описує (серед іншого) ідентифікатори токенів та кінцеву точку UserInfo. Перший надає набір претензій (хто ви є, коли маркер виданий тощо) та, можливо, підпис для підтвердження справжності токена за допомогою опублікованого відкритого ключа, не вимагаючи послуги вище за течією), а другий надає наприклад, запитуючи ім’я / прізвище користувача, електронну пошту та подібні біти інформації, і все це стандартизовано (на відміну від спеціальних розширень на OAuth, якими користувалися люди до стандартизованих речей OpenID Connect).

Обидва протоколи були створені з різних причин. OAuth створений для надання дозволу третім сторонам на доступ до ресурсів. OpenID був створений для децентралізації перевірки ідентичності. Цей веб-сайт зазначено:

OAuth - це протокол, призначений для перевірки особи кінцевого користувача та надання дозволу третій стороні. Ця перевірка призводить до позначення. Третя сторона може використовувати цей маркер для доступу до ресурсів від імені користувача. Токени мають розмах. Область використовується для перевірки, чи доступний ресурсу користувачеві, чи ні

OpenID - це протокол, який використовується для децентралізованої аутентифікації. Автентифікація стосується ідентичності; Створення користувача - це насправді людина, якою він претендує. Децентралізуючи це, означає, що ця послуга не знає про існування будь-яких ресурсів чи програм, які потрібно захистити. Це ключова відмінність OAuth від OpenID.

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

OAuth 2.0 - протокол безпеки. Протокол авторизації НІКОЛИ Аутентифікація NOR не має.

Автентифікація за визначенням дає відповіді на два питання.

1. Хто користувач?
2. Чи присутній зараз користувач у системі?

OAuth 2.0 має такі типи грантів

• client_credentials: коли одному додатку потрібно взаємодіяти з іншим додатком та змінювати дані кількох користувачів.
• author_code: Користувач делегує сервер авторизації для випуску access_token, який клієнт може використовувати для доступу до захищеного ресурсу
• refresh_token: Коли термін доступу_token закінчується, маркер оновлення може бути використаний, щоб отримати свіжий access_token
• пароль: Користувач надає свої облікові дані для входу клієнту, який викликає сервер авторизації та отримує access_token

Усі 4 мають одне спільне - артефакт access_token, який можна використовувати для доступу до захищеного ресурсу.

Access_token не дає відповіді на два запитання, на які повинен відповісти протокол "Автентифікація".

приклад для пояснення OAuth 2.0 (кредити: OAuth 2 в дії, Manning Publications)

Поговоримо про шоколад. З шоколаду ми можемо зробити багато кондитерських виробів, включаючи цукерки, морозиво та торти. Але жодне з них не можна прирівнювати до шоколаду, тому що для виготовлення кондитерських виробів потрібно багато інших інгредієнтів, таких як вершки та хліб, навіть якщо шоколад звучить як основний інгредієнт. Аналогічно OAuth 2.0 - це шоколад, а файли cookie, інфраструктура TLS, постачальники ідентичності - це інші інгредієнти, необхідні для забезпечення функціональності "Автентифікація".

Якщо ви хочете Автентифікацію, ви можете перейти до OpenID Connect, яка забезпечує "id_token", окрім access_token, який відповідає на питання, на які повинен відповідати кожен протокол аутентифікації.

OAuth будує автентифікацію поверх авторизації: Користувач делегує доступ до своєї ідентичності додатку, який потім стає споживачем API ідентифікації, таким чином з'ясовуючи, хто в першу чергу авторизував клієнта http://oauth.net/ статті / автентифікація /