На высоком уровне, как работает OAuth 2?

Как я понимаю, следующая цепочка событий возникает в OAuth 2, чтобы Site-A мог получить доступ к информации пользователя от Site-B.

  • Site-A регистрируется на Site-B и получает секрет и идентификатор.
  • Когда Пользователь сообщает Site-A для доступа к Site-B, Пользователь отправляется на Site-B, где он сообщает Site-B, что он действительно хотел бы дать Site-A разрешений для конкретной информации.
  • Site-B перенаправляет Пользователь обратно на Site-A вместе с авторизационным кодом.
  • Site-A затем передает этот код авторизации вместе с его тайной обратно на Site-B в обмен на токен безопасности.
  • Site-A затем отправляет запросы Site-B от имени Пользователь, связывая токен безопасности вместе с запросами.

Как все это работает с точки зрения безопасности и шифрования на высоком уровне? Как OAuth 2 защищает от таких вещей, как повторные атаки, используя токен безопасности?

542
18 янв. '11 в 20:44
источник поделиться
9 ответов

Основываясь на том, что я прочитал, так все работает:

Общий поток, указанный в вопросе, верен. На шаге 2 пользователь X аутентифицируется и также разрешает доступ на сайт A к информации о пользователе X на сайте B. На шаге 4 сайт передает свой секрет обратно на сайт B, аутентифицируя себя, а также код авторизации, указывая, что он запрашивает (токен доступа пользователя X).

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

OAuth 2 не имеет защиты от повторных атак Token Security или Secret. Вместо этого он полностью полагается на сайт B, который несет ответственность за эти элементы, и не позволяет им выйти, а на них отправляется через https во время транзита (https защитит параметры URL-адреса).

Цель шага авторизационного кода - просто удобство, и код авторизации не особо чувствителен сам по себе. Он предоставляет общий идентификатор токена доступа пользователя X для сайта A при запросе на сайт B для токена доступа пользователя X. Идентификатор пользователя User X на сайте B не работал бы, потому что может быть много выдающихся токенов доступа, ожидающих одновременного распространения на разные сайты.

129
10 февр. '11 в 1:34
источник

Связанные вопросы


Похожие вопросы

Как работает OAuth 2.0 в реальной жизни:

Я ехал по пекарне Олаф по дороге, чтобы работать, когда увидел в окошке самый вкусный пончик - я имею в виду, что дело в том, что капало шоколадное благо. Поэтому я вошел и потребовал: "У меня должен быть этот пончик!". Он сказал: "Конечно, это будет 30 долларов".

Да, я знаю, 30 долларов за один пончик! Это должно быть вкусно! Я потянулся за своим кошельком, когда вдруг услышал, как шеф-повар кричит "НЕТ! Нет пончиков для тебя". Я спросил: почему? Он сказал, что только принимает банковские переводы.

Серьезно? Да, он был серьезен. Я почти ушел прямо туда, но потом пончик позвал меня: "Ешь меня, я вкусный...". Кто я такой, чтобы не подчиняться приказам с пончика? Я сказал хорошо.

Он вручил мне записку с его именем на ней (шеф-повар, а не пончик): "Скажи им, что Олаф послал тебя". Его имя уже было на заметке, поэтому я не знаю, что сказать, но это нормально.

Я проехал полтора часа в свой банк. Я передал записку кассиру; Я сказал ей, что Олаф послал меня. Она дала мне один из тех взглядов, который говорит: "Я могу читать".

Она взяла мою записку, попросила мой идентификатор, спросила меня, сколько денег было в порядке, чтобы дать ему. Я сказал ей 30 долларов. Она сделала какую-то надпись и протянула мне еще одну записку. У этого был куча цифр на нем, я догадался, что они отслеживают записи.

В этот момент я голодаю. Я выбежал оттуда, через полтора часа я вернулся, стоя перед Олафом, и моя заметка расширилась. Он взял его, посмотрел и сказал: "Я вернусь".

Я думал, что он получает мой пончик, но через 30 минут я начал получать подозрение. Поэтому я спросил парня за прилавком "Где Олаф?". Он сказал: "Он пошел, чтобы получить деньги". "Что вы имеете в виду?". "Он принимает к сведению банк".

Да... Олаф взял записку, которую банк дал мне и вернулся в банк, чтобы получить деньги из моего счета. Поскольку у него была записка, которую банк дал мне, банк знал, что он был тем парнем, о котором я говорил, и потому что я разговаривал с банком, которого они знали, чтобы дать ему только 30 долларов.

Должно быть, мне пришлось долго размышлять об этом, потому что к тому времени, когда я поднял глаза, Олаф стоял передо мной, наконец, передал мне мой пончик. Прежде чем я ушел, мне пришлось спросить: "Олаф, ты всегда продавал пончики таким образом?". "Нет, я делал это по-другому".

Да. Когда я возвращался к своей машине, зазвонил мой телефон. Я не потрудился ответить, наверное, моя работа призывала уволить меня, мой босс такой ***. Кроме того, я был доволен мыслью о процессе, который я только что пережил.

Я имею в виду думать об этом: я смог позволить Олафу взять 30 долларов из моего банковского счета, не предоставив ему информацию о моей учетной записи. И мне не пришлось беспокоиться о том, что он выведет слишком много денег, потому что я уже сказал банку, что ему разрешено брать только 30 долларов. И банк знал, что он был подходящим парнем, потому что у него была записка, которую они дали мне, чтобы дать Олафу.

Хорошо, конечно, я бы отдал ему 30 долларов из кармана. Но теперь, когда у него была такая записка, я мог просто сказать банку, чтобы он забирал по 30 долларов каждую неделю, тогда я мог просто появиться в пекарне, и мне больше не нужно было ходить в банк. Я мог бы даже заказать пончик по телефону, если бы захотел.

Конечно, я бы никогда этого не делал - этот пончик был отвратительным.

Интересно, имеет ли этот подход более широкое применение. Он упомянул, что это был его второй подход, я мог бы назвать его Olaf 2.0. В любом случае, мне лучше вернуться домой, я должен начать искать новую работу. Но не раньше, чем я получаю один из тех клубничных коктейлей из этого нового места по всему городу, мне нужно что-то, чтобы смыть вкус этого пончика.

1341
12 сент. '15 в 4:26
источник

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

Вот пример использования:

  1. Я захожу в LinkedIn и хочу подключить друзей, которые находятся в моих контактах Gmail. LinkedIn поддерживает это. Он будет запрашивать безопасный ресурс (мой список контактов Gmail) от Gmail. Поэтому я нажимаю эту кнопку:
    Add Connection

  2. При открытии учетной записи и пароля появляется веб-страница, на которой отображается страница входа в Gmail:
    Add Connection

  3. Затем Gmail показывает страницу согласия, где я нажимаю "Принять": Add Connection

  4. Теперь LinkedIn может получить доступ к моим контактам в Gmail: Add Connection

Ниже приведена блок-схема примера выше:

Add Connection

Шаг 1. LinkedIn запрашивает токен с сервера авторизации Gmail.

Шаг 2. Сервер авторизации Gmail аутентифицирует владельца ресурса и показывает пользователю страницу согласия. (пользователь должен войти в Gmail, если он еще не вошел в систему)

Шаг 3. Пользователь разрешает LinkedIn получить доступ к данным Gmail.

Шаг 4: сервер авторизации Gmail отвечает обратно токеном доступа.

Шаг 5. LinkedIn вызывает Gmail API с этим токеном доступа.

Шаг 6. Сервер ресурсов Gmail возвращает ваши контакты, если токен доступа действителен. (Токен будет проверен сервером ресурсов Gmail)

Вы можете получить больше информации об OAuth здесь.

99
09 окт. '14 в 10:38
источник

Рисунок 1, снятый с RFC6750:

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+
24
04 авг. '16 в 1:04
источник

Вот как работает Oauth 2.0, хорошо объясненный в в этой статье

введите описание изображения здесь

13
10 мая '17 в 21:28
источник

Это драгоценный камень:

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

Очень короткое резюме:

OAuth определяет четыре роли:

  • Владелец ресурса
  • Клиент
  • Сервер ресурсов
  • Сервер авторизации

У вас (Владелец ресурсов) есть мобильный телефон. У вас несколько разных учетных записей электронной почты, но вы хотите, чтобы все ваши учетные записи электронной почты находились в одном приложении, поэтому вам не нужно продолжать переключение. Таким образом, ваш GMail (Клиент) запрашивает доступ (через Yahoo Authorization Server) к вашим электронным письмам Yahoo (Resource Server), чтобы вы могли читать обе письма в своем заявлении GMail.

Причина OAuth существует в том, что GMail не гарантирует, что GMail сохранит ваше имя пользователя и пароль Yahoo.

введите описание изображения здесь

10
11 июня '17 в 0:22
источник

Другой ответ очень подробный и затрагивает основную часть вопросов, поднятых OP.

Чтобы разработать и конкретно рассмотреть вопрос OP "Как OAuth 2 защищает от таких вещей, как повторные атаки с использованием маркера безопасности?", в официальных рекомендациях по реализации OAuth 2 есть две дополнительные защиты:

1) Токены обычно имеют короткий срок действия (http://tools.ietf.org/html/rfc6819#section-5.1.5.3):

Коротким сроком действия для токенов является средство защиты от следующие угрозы:

  • переигровка...

2) Когда токен используется сайтом А, рекомендация заключается в том, что он будет представлен не как параметры URL-адреса, а в поле заголовка запроса авторизации (http://tools.ietf.org/html/rfc6750):

Клиенты ДОЛЖНЫ выполнять аутентифицированные запросы с маркером-носителем, используя поле заголовка запроса "Авторизация" с HTTP-адресом "На предъявителя" схема авторизации....

Метод "application/x-www-form-urlencoded" НЕ ДОЛЖЕН использоваться за исключением контекстов приложений, в которых участвующие браузеры не имеют доступ к полю заголовка запроса авторизации....

Параметр запроса URI... включен в текущее использование документа; его использование не рекомендуется из-за его недостатков в области безопасности

7
24 апр. '13 в 17:26
источник

Вот, пожалуй, самое простое объяснение того, как OAuth2 работает для всех 4 типов предоставления, то есть для 4 разных потоков, где приложение может получить токен доступа.

сходство

Все потоки грантовых типов имеют 2 части:

  • Получить токен доступа
  • Использовать токен доступа

Вторая часть "Использовать токен доступа" одинакова для всех потоков.

разница

Первая часть потока "получить токен доступа" для каждого типа предоставления варьируется.

Тем не менее, в целом часть "получить токен доступа" может быть обобщена как состоящая из 5 шагов:

  1. Предварительно зарегистрируйте свое приложение (клиент) у поставщика OAuth, например, в Twitter и т.д., Чтобы получить идентификатор клиента/секрет
  2. Создайте кнопку входа в социальную сеть с идентификатором клиента и необходимыми областями/разрешениями на своей странице, чтобы при нажатии пользователь перенаправлялся к провайдеру OAuth для аутентификации
  3. OAuth-провайдер запрашивает у пользователя разрешение на ваше приложение (клиент)
  4. OAuth-провайдер выдает код
  5. Приложение (клиент) получает токен доступа

Ниже приведена диаграмма, показывающая, как каждый поток типов грантов отличается на основе 5 шагов.

Эта диаграмма из https://blog.oauth.io/introduction-oauth2-flow-diagrams/

enter image description here

Каждый имеет разные уровни сложности реализации, безопасности и вариантов использования. В зависимости от ваших потребностей и ситуации вам придется использовать один из них. Какой использовать?

Учетные данные клиента: если ваше приложение обслуживает только одного пользователя

Пароль владельца ресурса: этот параметр следует использовать только в качестве крайней меры, поскольку пользователь должен передать свои учетные данные приложению, что означает, что приложение может делать все, что может пользователь

Код авторизации: лучший способ получить авторизацию пользователя

Неявный: если ваше приложение мобильное или одностраничное

Более подробное объяснение выбора здесь: https://blog.oauth.io/choose-oauth2-flow-grant-types-for-app/

1
10 сент. '18 в 4:20
источник

Для другой метафоры, которая помогает понять основы на фундаментальном уровне, я написал блог и сделал короткое видео. Я использую простую для понимания аналогию, чтобы разбить ее.

Блог OAuth 2.0

Видео OAuth 2.0

enter image description here

0
17 апр. '19 в 19:26
источник

Посмотрите другие вопросы по метке или Задайте вопрос