OAuth 2.0 має безліч робочих процесів. У мене є кілька питань щодо двох.

1. Потік коду авторизації - Користувач входить із програми клієнта, сервер авторизації повертає код авторизації в додаток. Потім додаток обмінює код авторизації для маркера доступу.
2. Неявний потік грантів - Користувач входить із програми клієнта, сервер авторизації безпосередньо видає маркер доступу до клієнтської програми.

Яка різниця між двома підходами з точки зору безпеки? Хто з них безпечніший і чому?

Я не бачу причини, чому додатковий крок (код авторизації обміну на маркер) додається в одному робочому потоці, коли сервер може безпосередньо видавати маркер доступу.

На різних веб-сайтах написано, що потік кодів авторизації використовується, коли клієнтська програма може захищати облікові дані. Чому?

Це access_tokenте, що вам потрібно викликати захищений ресурс (API). У потоці Коду авторизації є два етапи, щоб отримати його:

1. Користувач повинен аутентифікувати та повернути codeспоживача API (називається "Клієнт").
2. "Клієнт" API (зазвичай ваш веб-сервер) обмінюється codeотриманим в №1 на access_tokenаутентифікацію себе з a client_idіclient_secret
3. Потім він може викликати API за допомогою access_token.

Отже, є подвійна перевірка: користувач, який володіє ресурсами, що з’являються через API та клієнт, що використовує API (наприклад, веб-додаток). І те й інше підтверджено для доступу. Зверніть увагу на "авторизаційний" характер OAuth тут: користувач надає доступ до свого ресурсу (через codeповернений після аутентифікації) додаток, додаток отримує access_tokenі дзвонить від імені користувача.

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

Неявне потік зазвичай використовується в сценаріях , де зберіганні client idі client secretне рекомендується (пристрій, наприклад, хоча багато хто робить це так чи інакше). Ось що означає відмова від відповідальності. Люди мають доступ до клієнтського коду, і тому вони можуть отримати облікові дані та зробити вигляд, що вони стають клієнтами ресурсів. У неявному потоці всі дані є нестабільними, і в додатку нічого не зберігається.

Я додам тут щось, що, на мою думку, не було зрозуміло у наведених вище відповідях:

• Авторизація-Код-Потік дозволяє остаточному маркеру доступу ніколи не діставатись і ніколи не зберігатися на пристрої за допомогою браузера / програми . Тимчасовий код авторизації надається машині разом із браузером / додатком, який потім надсилається серверу. Потім сервер може обміняти його токеном повного доступу та мати доступ до API та ін. Користувач із браузером отримує доступ до API лише через сервер із маркером.
• Неявний потік може включати лише дві сторони, а кінцевий маркер доступу зберігається на клієнті за допомогою браузера / програми. Якщо цей веб-переглядач / додаток порушений, то їх авторський маркер може бути небезпечним.

Т.Л., д - р не використовувати неявний потік , якщо ви не довіряєте машині користувачів , щоб тримати лексеми , але ви робите довіряти свої власні серверів.

Різниця між обома полягає в тому, що:

1. У нечіткому потоці маркер повертається безпосередньо через URL-адресу переадресації зі знаком "#", і це використовується в основному у клієнтах javascript або мобільних додатках, які не мають власного сервера, і клієнту не потрібно вказувати свою таємницю в деяких реалізаціях .

2. У потоці коду авторизації код повертається з "?" щоб бути читабельним з боку сервера, тоді сторона сервера повинна надати клієнтській таємниці цього разу токен маркера, щоб отримати маркер як об’єкт json з сервера авторизації. Він використовується в тому випадку, якщо у вас є сервер додатків, який може це впоратися і зберігати маркер користувача зі своїм профілем у власній системі, і в основному використовується для звичайних мобільних додатків.

тож залежить від характеру вашої клієнтської програми, який ще один захищений "Код авторизації", оскільки це запит секрету на клієнті, і маркер може бути надісланий між сервером авторизації та клієнтською програмою на дуже захищеному з'єднанні, і постачальник авторизації може обмежити деяких клієнтів використовувати лише "Код авторизації" та заборонити неявне використання

Неявний грант аналогічний наданню коду авторизації з двома різними відмінностями.

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

По-друге, замість сервера авторизації повертає код авторизації, який обмінюється на маркер доступу, сервер авторизації повертає маркер доступу.

Докладні відомості можна знайти тут http://oauth2.thephpleague.com/authorization-server/which-grant/

Неявний потік

Переваги

• Найпростіший у виконанні

Недоліки

• Маркери доступу, видимі для браузера
• Походження токенів доступу не можна визначити
• Маркери доступу не можуть закінчитися (відповідно до політики Google)

Потік коду авторизації

Переваги

• Найбезпечніший
• Токени доступу та лексеми для оновлення можна створити лише в тому випадку, якщо відомий загальний секрет
• Можна покращити нові функції безпеки та UX, коли вони стануть доступними

Недоліки

• Потрібно реалізувати кілька кінцевих точок auth

Цитування: https://developers.google.com/action/develop/identity/oauth2-overview#supported_oauth_20_flows

Дозвольте підвести підсумки пунктів, які я дізнався з наведених вище відповідей, і додам деякі власні розуміння.

Потік коду авторизації !!!

• Якщо у вас є сервер веб-додатків, який виступає клієнтом OAuth
• Якщо ви хочете мати довгий доступ
• Якщо ви хочете мати офлайн-доступ до даних
• коли ви несете відповідальність за дзвінки api, які здійснює ваш додаток
• Якщо ви не хочете просочувати ваш маркер OAuth
• Якщо ви не хочете, щоб програма запускалася через потік авторизації кожного разу, коли їй потрібен доступ до даних. ПРИМІТКА. Потік непередбачених грантів не містить маркер оновлення, тому якщо сервер авторизації регулярно закінчує маркери доступу, вашій програмі потрібно буде запускатись через потік авторизації, коли йому потрібен доступ.

Безсумнівний потік грантів !!!

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

Хто з них безпечніший і чому?

Обидва вони безпечні, це залежить від середовища, яким ви користуєтесь.

Я не бачу причини, чому додатковий крок (код авторизації обміну на маркер) додається в одному робочому потоці, коли сервер може безпосередньо видавати маркер доступу.

Це просто. Ваш клієнт не захищений. Давайте розберемося в деталях.

Подумайте, що ви розробляєте програму проти Instagram API, тому ви реєструєте додаток Instagramі визначаєте, який API'sвам потрібен. Instagramнадасть вам client_idіclient_secrect

На вашому веб-сайті ви встановлюєте посилання, яке говорить. "Приходьте та використовуйте мою програму". Клацнувши на цьому, ваша веб-програма повинна зробити два дзвінки Instagram API.

Firstнадіслати запит до Instagram Authentication Serverпараметрів нижче.

1. `response_type` with the value `code`
2. `client_id` you have get from `Instagram`
3. `redirect_uri` this is a url on your server which do the second call
4. `scope` a space delimited list of scopes
5. `state` with a CSRF token. 

Ви не надсилаєтеclient_secret , Ви не можете довіритися клієнту (Користувачеві та його браузеру, які намагаються використовувати вашу програму). Клієнт може переглядати URL або сценарій java та client_secrectлегко знайти ваш . Ось чому вам потрібен ще один крок.

Ви отримуєте codeта state. codeТут temporaryі не зберігається де - небудь.

Потім ви secondтелефонуєте Instagram API(зі свого сервера)

 1. `grant_type` with the value of `authorization_code`
 2. `client_id` with the client identifier
 3. `client_secret` with the client secret
 4. `redirect_uri` with the same redirect URI the user was redirect back to
 5. `code` which we have already received.

Оскільки дзвінок робиться з нашого сервера, ми можемо безпечно використовувати client_secret(що показує, як ми), codeщо показує, що користувач надав client_idможливість використовувати ресурс.

У відповідь у нас буде access_token

З практичної точки зору (що я зрозумів) Основна причина виникнення потоку коду Authz:

1. Підтримка токенів оновлення (довгостроковий доступ додатками від імені Користувача), не підтримується неявно: див. Https://tools.ietf.org/html/rfc6749#section-4.2
2. Підтримка сторінки згоди - це місце, де Власник ресурсу може контролювати, який доступ надавати (Вид дозволів / сторінки авторизації, які ви бачите в google). Те саме немає в неявних. Дивіться розділ: https://tools.ietf.org/html/rfc6749#section-4.1 , пункт (B)

"Сервер авторизації автентифікує власника ресурсу (через користувальницький агент) і встановлює, надає власник ресурсу чи відмовляє клієнту в запиті на доступ"

Крім цього, використовуючи маркери оновлення, програми можуть отримати довгостроковий доступ до даних користувачів.

Здається, два ключові моменти, не обговорені до цього часу, пояснюють, чому об’їзд у Код авторизації Грант типу додає безпеку.

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

Більш дрібна версія:

Далі я дотримуюся терміналогії OAuth 2, визначеної в RFC (це швидке зчитування): сервер ресурсів , клієнт , сервер авторизації , власник ресурсу .

Уявіть, що ви хочете, щоб якийсь сторонній додаток (= клієнт) отримував доступ до певних даних вашого облікового запису Google (= сервер ресурсів). Припустимо, Google використовує OAuth 2. Ви власник ресурсу для облікового запису Google, але зараз ви керуєте стороннім додатком.

По-перше, клієнт відкриває браузер, щоб надіслати вам захищену URL-адресу сервера авторизації Google. Тоді ви затверджуєте запит на доступ, і сервер авторизації відсилає вас до попередньо заданої клієнтом URL-адреси переспрямування з кодом авторизації в рядку запиту. Тепер про два ключових моменти:

1. URL-адреса цього переадресації виявляється в історії веб-переглядача . Таким чином, ми не хочемо, щоб тут існував маркер прямого доступу, який можна використовувати прямо. Короткочасний код авторизації є менш небезпечним в історії. Зверніть увагу , що неявний тип Гранта дійсно поставив маркер в історії.
2. Захищеність цього переадресації залежить від HTTPS-сертифіката клієнта , а не від сертифіката Google. Таким чином, ми отримуємо захищеність передачі клієнта як додатковий вектор атаки (Щоб це було неминуче, клієнту потрібно не використовувати JavaScript. Оскільки в іншому випадку ми могли б передавати код авторизації через фрагмент URL, де код не проходив би через мережу. це може бути причиною того, чому неявний Grant Тип, який робить використовувати фрагмент URL, який використовується для бути рекомендований для клієнтів JavaScript, незважаючи на те, що це більше не так.)

За типом надання авторизаційного коду маркер, нарешті, отримується викликом від клієнта на сервер авторизації, де безпека передачі залежить лише від сервера авторизації , а не від клієнта.