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

Question 1

Терминология OAuth уже давно меня беспокоит. Авторизация OAuth, как некоторые предлагают, или это аутентификация?

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

Является ли аутентификация OAuth (в каждой статье говорится, что это не так), что, как я понимаю, требует от пользователя предоставления учетных данных, что, в свою очередь, доказывает, что пользователь должен / не должен иметь доступ?

Таким образом, кажется, что OAuth не является аутентификацией авторизации NOR, поскольку они должны выполняться другими процессами. Так что, черт возьми, это? Это процесс передачи токена? Неужели это пустое слово, не имеющее особого значения?

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

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, где стороннее приложение может получить идентификационную информацию пользователя, управляемую службой.

^{(Извините, эти определения являются выдержками со страницы обзора моей компании)}

Определения с точки зрения разработчиков

Аутентификация - это процесс определения субъекта (= уникального идентификатора) конечного пользователя. Есть много способов определить предмет. ID и пароль, отпечатки пальцев, распознавание радужной оболочки глаза и т. Д.

Авторизация - это процесс связывания субъекта с запрошенными разрешениями и клиентским приложением, которое запросило разрешения. Маркер доступа представляет ассоциацию.