Подтвердить что ты не робот

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

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

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

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

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

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

4b9b3361

Ответ 1

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

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

Конечная точка авторизации используется для взаимодействия с владельцем ресурса и получения разрешения на авторизацию. Сервер авторизации ДОЛЖЕН сначала проверить личность владельца ресурса. Способ, которым сервер авторизации аутентифицирует владельца ресурса (например, имя пользователя и пароль для входа, сеансовые куки), выходит за рамки данной спецификации.


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

enter image description here

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

enter image description here

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


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

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

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


Смотрите также

  1. Полноценный разработчик OAuth и OpenID Connect рассказывает о результатах
  2. Диаграммы и фильмы всех потоков OAuth 2.0
  3. Диаграммы всех потоков OpenID Connect
  4. Самое простое руководство по OAuth 2.0

Ответ 2

OAuth не является API или службой: это открытый стандарт для authorization и любой может его реализовать. OAuth был создан как ответ на authentication pattern прямой authentication pattern.

Это OAuth:

How can I allow an app to access my data without necessarily giving it my password?

OAuth Актеры

enter image description here

OAuth != authentication

OAuth не аутентификация. Это протокол авторизации или, что еще лучше, протокол делегирования.

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

Authentication - это процесс проверки личности (кем они себя называют)

Authorization - это процесс проверки того, что кому-то разрешено делать (разрешения)

Узнайте больше здесь, здесь

Ответ 3

OAuth 2.0 - это протокол безопасности. Это не протокол авторизации NOR авторизации.

Аутентификация по определению отвечает на два вопроса.

  1. Кто такой пользователь?
  2. Пользователь в данный момент присутствует в системе?

OAuth 2.0 имеет следующие типы грантов

  • client_credentials: когда одно приложение должно взаимодействовать с другим приложением и изменять данные нескольких пользователей.
  • authorization_code: пользователь делегирует серверу авторизации выдачу access_token, который клиент может использовать для доступа к защищенному ресурсу.
  • refresh_token: когда срок действия access_token истекает, токен обновления можно использовать для получения нового access_token
  • пароль: пользователь предоставляет свои учетные данные для входа клиенту, который вызывает сервер авторизации и получает access_token

Все 4 имеют одну общую черту, access_token, артефакт, который можно использовать для доступа к защищенному ресурсу.

Access_token не дает ответа на 2 вопроса, на которые должен ответить протокол "Аутентификация".

Пример объяснить OAuth 2.0 (кредиты: OAuth 2 в действии, публикация Manning)

Давай поговорим о шоколаде. Из шоколада мы можем приготовить много кондитерских изделий, включая помадку, мороженое и пирожные. Но ни один из них не может быть приравнен к шоколаду, потому что для приготовления кондитерских изделий необходимо множество других ингредиентов, таких как сливки и хлеб, хотя шоколад звучит как основной ингредиент. Аналогично, OAuth 2.0 - это шоколад, а cookie файлы, инфраструктура TLS, провайдеры идентификации - другие компоненты, которые необходимы для обеспечения функциональности "Аутентификация".

Если вы хотите аутентификацию, вы можете пойти на OpenID Connect, который предоставляет "id_token", кроме access_token, который отвечает на вопросы, на которые должен отвечать каждый протокол аутентификации.