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

Ответ 1

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

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

Ответ 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 4

Рисунок 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 ---|               |
     +--------+                               +---------------+

Ответ 5

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

Ответ 6

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

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

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

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

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

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

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

Ответ 7

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

Ответ 8

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

сходство

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

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

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

разница

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

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

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

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

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

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

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

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

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

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

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

Ответ 9

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

Блог OAuth 2.0

Видео OAuth 2.0