Как OAuth 2 защищает от таких вещей, как повторные атаки с использованием маркера безопасности? - PullRequest
546 голосов
/ 18 января 2011

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

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

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

Ответы [ 8 ]

1354 голосов
/ 12 сентября 2015

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

130 голосов
/ 10 февраля 2011

Исходя из того, что я прочитал, вот как все это работает:

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

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

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

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

101 голосов
/ 09 октября 2014

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 вызывает API Gmail с этим токеном доступа.

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

Подробнее об OAuth можно узнать здесь .

24 голосов
/ 04 августа 2016

Рисунок 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 ---|               |
     +--------+                               +---------------+
13 голосов
/ 10 мая 2017

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

enter image description here

10 голосов
/ 11 июня 2017

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

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

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

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

  1. Владелец ресурса
  2. Клиент
  3. Сервер ресурсов
  4. Сервер авторизации

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

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

enter image description here

8 голосов
/ 24 апреля 2013

Другой ответ очень подробный и касается большей части вопросов, поднятых ОП.

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

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

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

  • воспроизведение ...

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

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

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

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

3 голосов
/ 10 сентября 2018

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

Сходство

Все потоки типа гранта состоят из 2 частей:

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

2-я часть 'использовать токен доступа' одинакова для всех потоков

Difference

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

Тем не менее, в общем случае 'токен доступа' можно обобщить как состоящий из 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/

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...