Тут в блозі завалялось вже більше десяти чернеток, пора потрохи розгрібати. Наступна нотатка повинна допомогти розібратись в документації по протоколу OAuth. Щоправда для того аби щось запрограмувати все одно доведеться читати документацію конкретного API.

Аутентифікація – перевірка того факту. що суб’єкт – той за кого себе видає.
Авторизація – перевірка того факту, що суб’єкт має право на доступ до певного ресурсу.
Credentials (мандат) – реєстраційна інформація потрібна для аутентифікації.

В схемі протоколу OAuth описані три агенти: клієнт (споживач, client, consumer), сервер (провайдер послуги, server, service provider) і власник ресурсу (користувач, user, resource owner).

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

Дуже часто клієнт працює від чужого імені. Наприклад браузер працює від імені користувача, використовуючи реєстраційну інформацію (зазвичай логін та пароль) яку йому довірив користувач. Клієнтом може бути веб-застосунок, який поділяється на фронт-енд та бекенд, і запити до сервера йдуть з бекенда. Але якою б не була архітектура клієнта – він все одно діє від імені користувача як одне ціле.

Захищений ресурс – це те що зберігається чи надається сервером, і потребує аутентифікації для доступу. Ресурси належать і контролюються власником ресурсу – користувачем. Будь-хто хто потребує доступу до захищених ресурсів повинен отримати дозвіл на авторизацію від власника користвача (що гарантується сервером). Ресурсом можуть бути як дані (документи, медіа, контакти) так і сервіси (публікація новин в блозі, переказ коштів і т.п).

Протокол OAuth дозволяє користувачу надати доступ клієну до захищеного ресурсу не передаючи йому свій мандат. Тобто клієнт аутентифікується як окремий клієнт і працює від свого імені з дозволу користувача.

OAuth використовує три типи облікової інформації – облікова інформація клієнта, тимчасову та токени. Специфікація називає їх відповідно consumer key and secret (client credentials), request token and secret (temporary credentials), та access token and secret (token credentials).

Перші в параметрах запиту називаються відповідно:

{
    'oauth_consumer_key': 'anonymous',
    'oauth_consumer_secret': 'anonymous'
}

Використовуються для аутентифікації клієнта. Дозволяє серверу вияснити який клієнт хоче отримати доступ. В даному випадку це анонімний клієнт. Щоб клієнт не був анонімним його реєструють на сервері де отримують відповідний ключ і секрет. Сервер звертається до користувача з повідомленням про те що хтось просить доступ до певних дій. Виглядати це може наприклад так:

Після того як користувач дає дозвіл, клієнту (зазвичай за допомогою GET запиту, за адресою яка повідомляється серверу параметром callback_url, хоча можливо існують і інші способи) передають тимчасовий мандат (токен та секрет запиту).

Клієнт звертається до сервера з цим токеном та секретом, і сервер замінює їх на постійні. Цей крок мені дещо незрозумілий (яку схему атаки він дозволяє уникнути?), але чомусь так воно працює.

Посилання:

• OAuth2 – промінчик світла в темному царстві?
• OAuth для інтернет-маркетологів (в Google Ads APIs Python Client Libraries)

Filed under: Кодерство, Павутина Tagged: API