Авторизація OAuth проти автентифікації

Question 1

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

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

Чи вимагає автентифікація OAuth (кожна стаття каже, що це не так), яку, на мою думку, користувач повинен надати облікові дані, що в свою чергу доводить, що користувач повинен / не повинен мати доступу?

Отже, здається, що OAuth не є авторизацією або АВТОРИФІКАЦІЄЮ, оскільки вони повинні виконуватися іншими процесами. То що це за біса? Це процес передачі маркера? Це пухнасте слово, яке насправді не має конкретного значення?

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

Question 2

OAuth - це специфікація для авторизації

OAuth 2.0 - це специфікація для авторизації, але НЕ для автентифікації. RFC 6749, 3.1. Кінцева точка авторизації прямо говорить наступне:

Кінцева точка авторизації використовується для взаємодії з власником ресурсу та отримання дозволу авторизації. Сервер авторизації ПОВИНЕН спочатку перевірити особу власника ресурсу. Спосіб автентифікації сервера авторизації власника ресурсу (наприклад, ім'я користувача та пароль, сеансові файли cookie) виходить за рамки цієї специфікації .

Аутентифікація OAuth?

Аутентифікація надає інформацію про те, "хто такий". Авторизація містить інформацію про те, "хто кому надає які дозволи". Першим кроком авторизації є аутентифікація. Саме тому люди часто розгублені.

Існує багато бібліотек та служб, які використовують OAuth 2.0 для автентифікації. Його часто називають "соціальним входом", і це робить людей більш розгубленими. Якщо ви бачите "Аутентифікація OAuth" (а не "Авторизація OAuth"), це рішення, яке використовує OAuth для автентифікації.

OpenID Connect

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

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

Так, це зробило людей набагато більш розгубленими.

Визначення OAuth 2.0 та OpenID Connect в одному реченні

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

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

^{(Вибачте, ці визначення - це уривки зі сторінки огляду моєї компанії)}

Визначення з точки зору реалізаторів

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

Авторизація - це процес пов’язування суб’єкта із запитуваними дозволами та клієнтською програмою, яка вимагала дозволи. Токен доступу представляє асоціацію.