Як OAuth 2 захищає від таких речей, як повторна атака, використовуючи маркер безпеки?

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

1. Site-Aреєструється на Site-Bта отримує секрет та ідентифікатор.
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 захищає від таких речей, як повторна атака, використовуючи маркер безпеки?

Як працює OAuth 2.0 в реальному житті:

Я їхав по пекарні Олафа по дорозі на роботу, коли побачив у вікні найсмачніший пончик - я маю на увазі, річ капала шоколадну користь. Тож я зайшов всередину і зажадав "я мушу мати цей пончик!". Він сказав, що "впевнений, що це буде 30 доларів".

Так, я знаю, 30 доларів за один пончик! Це повинно бути смачно! Я потягнувся до свого гаманця, коли раптом почув, як шеф-кухар кричить "НІ! Немає пончика для тебе". Я запитав: чому? Він сказав, що приймає лише банківські перекази.

Серйозно? Так, він був серйозний. Я майже пішов прямо туди, але тоді пончик гукнув мені: "Їжте мене, я смачний ...". Хто я, щоб не виконувати замовлення з пончика? Я сказав добре.

Він передав мені записку із своїм прізвищем на ньому (шеф-кухар, а не пончик): "Скажи їм, що Олаф тебе послав". Його ім'я вже було на замітці, тому я не знаю, в чому сенс сказати, але гаразд.

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

Вона взяла мою записку, запитала мій ідентифікатор, запитала, скільки грошей було в порядку, щоб дати йому. Я сказав їй 30 доларів. Вона зробила кілька писанок і подала мені ще одну замітку. У цього була купа цифр, я здогадався, що так вони відстежують ноти.

У цей момент я голодую. Я кинувся звідти, через півтори години я повернувся, стоячи перед Олафом з простягнутою нотою. Він узяв, подивився і сказав: "Я повернусь".

Я думав, що він дістає мені пончик, але через 30 хвилин я почав підозріло. Тож я запитав хлопця за прилавком "Де Олаф?". Він сказав: "Він пішов отримати гроші". "Що ви маєте на увазі?". "Він бере до відома банк".

Так ... Олаф взяв записку, яку мені дали банк, і повернувся до банку, щоб отримати гроші з мого рахунку. Оскільки він мав записку, яку мені подарував банк, банк знав, що він хлопець, про якого я говорив, і тому, що я розмовляв з банком, вони знали, що він дасть йому лише 30 доларів.

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

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

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

Гаразд, я впевнений, що я віддав би йому 30 доларів з кишені. Але тепер, коли він мав цю записку, я міг просто сказати банку, щоб він давав йому 30 доларів щотижня, тоді я міг просто з’являтися в пекарні, і мені більше не довелося йти до банку. Я навіть міг би замовити пончик по телефону, якби хотів.

Звичайно, я ніколи цього не робив - цей пончик був огидним.

Цікаво, чи має такий підхід більш широке застосування. Він згадав, що це його другий підхід, я міг би назвати це Olaf 2.0. У будь-якому випадку мені краще повернутися додому, я повинен почати шукати нову роботу. Але не до того, як я дістану один із тих полуничних коктейлів з того нового місця по всьому місту, мені потрібно щось змити з смаку цього пончика.

На основі того, що я прочитав, ось як це працює:

Загальний потік, викладений у питанні, є правильним. На кроці 2 Користувач X має автентифікацію, а також авторизує доступ сайту A до інформації користувача User X про сайт B. На кроці 4 сайт передає свою таємницю назад на сайт B, автентифікуючи себе, а також код авторизації із зазначенням того, що запитує (маркер доступу користувача X).

Загалом, OAuth 2 насправді є дуже простою моделлю безпеки, і шифрування ніколи не потрапляє безпосередньо в гру. Натомість і Secret, і Token Security - це фактично паролі, і вся справа захищена лише безпекою з'єднання https.

OAuth 2 не захищає від повторних атак Token Security або Secret. Натомість він повністю покладається на те, що Сайт B несе відповідальність за ці елементи та не дає їм виходити, а також надсилає їх через https під час транзиту (https захищатиме параметри URL-адреси).

Метою кроку авторизаційного коду є просто зручність, а Кодекс авторизації самостійно не особливо чутливий. Він надає загальний ідентифікатор для маркера доступу користувача X для сайту A, коли запитує сайт B для маркера доступу користувача X. Ідентифікатор користувача Just User X на сайті B не працював, оскільки може бути багато видатних жетонів доступу, які чекають, щоб їх одночасно було роздано на різні сайти.

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

Ось демонстраційний випадок використання:

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 викликає API Gmail за допомогою цього маркера доступу.

Крок 6: Сервер ресурсів Gmail повертає ваші контакти, якщо маркер доступу дійсний. (Маркер буде підтверджений сервером ресурсів Gmail)

Більш детальну інформацію про OAuth ви можете отримати тут .

Фігура 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 ---|               |
     +--------+                               +---------------+

Ось як працює Oauth 2.0, добре пояснено в цій статті

Це дорогоцінний камінь:

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

Дуже короткий підсумок:

OAuth визначає чотири ролі:

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

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

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

Інша відповідь дуже детальна і стосується більшості питань, порушених ОП.

Щоб розробити та конкретно вирішити питання ОП "Як захищає 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 "Носій". ...

Метод "application / x-www-form-urlencoded" НЕ БУДЕ використовуватися, за винятком контекстів додатків, де браузери-учасники не мають доступу до заголовка поля "Авторизація". ...

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

Ось, мабуть, найпростіше пояснення того, як OAuth2 працює для всіх 4 типів грантів, тобто 4 різних потоків, де додаток може отримати маркер доступу.

Схожість

Усі потоки типів грантів мають 2 частини:

• Отримайте маркер доступу
• Використовуйте маркер доступу

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/