На высоком уровне, как работает 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 защищает от таких вещей, как повторные атаки, используя токен безопасности?

455
задан 18 янв. '11 в 20:44
источник поделиться
7 ответов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Теперь 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 здесь.

75
ответ дан 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 ---|               |
     +--------+                               +---------------+
17
ответ дан 04 авг. '16 в 1:04
источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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