Яка мета неявного типу надання дозволу в OAuth 2?

Я не знаю, чи просто у мене є якась сліпа пляма чи що, але я багато разів читав специфікацію OAuth 2 і переглядав архіви списку розсилки, і мені ще належить знайти гарне пояснення того, чому неявна грант потік для отримання жетонів доступу був розроблений. У порівнянні з Авторизаційним кодом Грант, здається, він просто відмовився від автентифікації клієнтів без дуже вагомих причин. Як це "оптимізовано для клієнтів, реалізованих у браузері за допомогою мови скриптів" (щоб цитувати специфікацію)?

Обидва потоки починаються однаково (джерело: http://tools.ietf.org/html/draft-ietf-oauth-v2-22 ):

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

Ось де розділяються потоки. В обох випадках URI перенаправлення в цій точці є деякою кінцевою точкою, розміщеною клієнтом:

• У потоці коду авторизації, коли агент користувача потрапляє на цю кінцеву точку з кодом авторизації в URI, код у цій кінцевій точці обмінюється кодом авторизації разом зі своїми клієнтськими обліковими даними на маркер доступу, який він може потім використовувати за необхідності. Наприклад, можна записати його на веб-сторінку, до якої може отримати доступ сценарій.
• Поточний потік повністю пропускає цей крок аутентифікації клієнта і просто завантажує веб-сторінку із сценарієм клієнта. Тут є милий трюк з фрагментом URL-адреси, який запобігає занадто багато передачі маркера доступу, але кінцевий результат по суті той самий: веб-сайт, розміщений клієнтом, обслуговує сторінку з деяким сценарієм, який може захопити маркер доступу. .
  

Звідси моє запитання: що тут було досягнуто, пропустивши крок аутентифікації клієнта?

Ось мої думки:

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

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

Тож відповідь на те, "що було здобуто?" це "простота".

Це там з міркувань безпеки, а не простоти.

Ви повинні врахувати різницю між агентом користувача та клієнтом :

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

Клієнт - це програмне забезпечення, яке хоче отримати доступ до ресурсів користувача на ресурсному сервері.

У випадку зв'язаного агента користувача та клієнта надається Код авторизації . Наприклад, користувач використовує веб-браузер (user-agent) для входу зі своїм обліковим записом Facebook на Kickstarter. У цьому випадку клієнт є одним із серверів Kickstarter, який обробляє входи користувачів. Цей сервер отримує маркер доступу та маркер оновлення від Facebook. Таким чином, цей тип клієнта, який вважається "захищеним", через обмежений доступ, маркери можуть бути збережені, а Kickstarter може отримати доступ до ресурсів користувачів і навіть оновити маркери доступу без взаємодії з користувачем.

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

Звичайне пояснення полягає в тому, що неявний грант простіше реалізувати під час використання клієнта JavaScript. Але я думаю, що це неправильний погляд на це. Якщо ви використовуєте клієнт JavaScript, який вимагає захищених ресурсів безпосередньо через XMLHttpRequest, то неявний грант - це ваш єдиний варіант, хоча він менш безпечний. *

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

Але - і це дуже легко пропустити - безпека потоку коду авторизації працює лише в тому випадку, якщо веб-сервер захищений сеансом, який встановлюється за допомогою аутентифікації користувача (логін). Без сеансу ненадійний користувач може просто робити запити на веб-сервер, використовуючи client_id, і це було б так само, як якщо б у користувача був маркер доступу. Додавання сеансу означає, що лише захищений ресурс може отримати доступ до захищених ресурсів. Client_id - це лише "ідентичність" веб-сайту JS, а не автентифікація зазначеного webapp.

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

Якщо веб-сервера немає, вам доведеться скористатися грантом Implicit. Але це означає, що маркер доступу піддається Інтернет. Якщо ненадійний користувач отримує доступ до нього, він може використовувати його до його закінчення. Це означає, що вони матимуть доступ до нього довше, ніж при наданні коду авторизації. Тож, можливо, ви захочете скоріше закінчити термін дії маркера та уникати доступу до більш чутливих ресурсів.

* РЕДАКТУВАННЯ: Останнім часом люди рекомендують уникати використання грантового підходу, навіть у веб-додатках без сервера. Натомість ви можете використовувати грант Коду авторизації, налаштований із порожнім секретом, а також PKCE. Надання коду auth-коду дозволяє уникнути зберігання маркера доступу в історії вашого браузера, а PKCE уникає його викриття, якщо хтось захоплює URL-адресу переадресації, щоб викрасти код автентифікації. У цьому випадку вам знадобиться сервер, щоб не повертати маркер оновлення, оскільки ваш клієнт, ймовірно, не може надійно зберігати його. І він повинен видавати маркер доступу з тими ж обмеженнями, які були згадані вище.

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

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

Однак наслідки для безпеки є значними. З http://tools.ietf.org/html/rfc6749#section-10.3 :

При використанні неявного типу дозволу маркер доступу передається у фрагменті URI, який може піддавати його стороннім сторонам.

З http://tools.ietf.org/html/rfc6749#section-10.16 :

Власник ресурсу може охоче делегувати доступ до ресурсу, надаючи маркер доступу зловмисному клієнту зловмисника. Це може бути пов’язано з фішингом чи іншим приводом ...

Я не впевнений, що я правильно розумію відповідь та коментар Дена. Мені здається, що у відповіді деякі факти вказані правильними, але це вказує саме на те, що запитувала ОП. Якщо я правильно розумію, головна перевага неявного потоку грантів полягає в тому, що такий клієнт, як програма JS (наприклад, розширення Chrome), не повинен розкривати клієнтську таємницю.

Ден Тафлін сказав:

... у потоці коду авторизації власнику ресурсу ніколи не потрібно бачити маркер доступу, тоді як у клієнтах JavaScript це неминуче. Однак секрет клієнта все ще може зберігатися від клієнтів javascript, використовуючи потік коду авторизації.

Можливо, я вас зрозумів неправильно, але клієнт (програма JS в цьому випадку) повинен передати клієнтські дані (ключ клієнта та секрет) на сервер ресурсів у потоці коду авторизації, правда? Клієнтську таємницю не можна "зберігати від JS".

Хоча Implicit Grant був розроблений для підтримки додатків, які не могли захистити клієнтську таємницю, включаючи додатки JavaScript на стороні клієнта, деякі провайдери впроваджують альтернативу, використовуючи Код авторизації, а не Client Secret. Програма OAuth 2.0 IETF RFC-6749 була опублікована в 2012 році, а нинішні рекомендації, деякі останні дискусії, починаються з 2017 року.

Дискусія 2017 року у списку розсилки IETF OAuth доступна у цих реалізаторів:

• Redhat: https://www.ietf.org/…/oauth/current/msg16966.html
• Deutsche Telekom: https://www.ietf.org/…/oauth/current/msg16968.html
• Smart Health IT: https://www.ietf.org/…/oauth/current/msg16967.html

Детальніше читайте тут:

• https://aaronparecki.com/oauth-2-simplified/
• https://aaronparecki.com/oauth-2-simplified/#single-page-apps

Раніше імпліцит рекомендовано для клієнтів без секрету, але його замінено за допомогою наданого Кодексу авторизації без секрету.

...

Раніше було рекомендовано, щоб додатки на основі браузера використовували потік "Неявно", який негайно повертає маркер доступу та не має кроку обміну токенів. З часу, коли специфікація була написана спочатку, найкраща галузева практика змінилася, рекомендуючи використовувати потік коду авторизації без секрету клієнта. Це надає більше можливостей для створення захищеного потоку, наприклад використання параметра стану. Список літератури: Redhat , Deutsche Telekom , Smart Health IT .

Перехід до Auth Code без Client Secret від Implicit Grant тут також згадується для мобільних додатків:

• https://aaronparecki.com/oauth-2-simplified/#mobile-apps

на додаток до інших відповідей важливо також усвідомити, що профіль непрямих даних дозволяє здійснювати потік лише переднього каналу на відміну від потоку коду авторизації, який вимагає зворотного виклику на сервер авторизації; це стає очевидним у OpenID Connect, який є протоколом SSO, побудованим поверх Auth 2.0, де імпліцитний потік нагадує досить популярну прив'язку SAML POST, а потік коду авторизації нагадує менш широко розгорнуту прив'язку артефакту SAML

У неявному потоці, якщо браузер користувача пошкоджений (злі розширення / вірус), корупція отримує доступ до ресурсів користувача і може спричинити погані речі.

У аутентичному потоці корупція не може, оскільки не знає клієнтської таємниці.

https://tools.ietf.org/html/rfc6749#page-8

Неявне

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

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

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

Я думаю, що Вілл Кейн відповів на це, сказав: "Немає користі для облікових даних клієнта з тієї ж причини. (Будь-який клієнт може спробувати використовувати цей потік.)" Також врахуйте, що redirect_uri для неявного потоку може бути "localhost" - немає зворотного виклику робиться з сервера авторизації для неявного потоку. Оскільки немає можливості попередньо довіряти клієнту, користувачеві доведеться схвалити звільнення претензій користувача.

Неявна грант дозволяє отримувати жетони від Кінцевої точки авторизації за допомогою a GET. Це означає, що сервер авторизації не повинен підтримувати CORS.

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

Історично існували інші причини впровадження неявного потоку, але, здається, вони в даний час переважують переваги безпеки, які надає дозвільний код, включаючи:

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

Я щойно стикався з деякою статтею про OAuth 2.0. Автор заявляє, що причина непрямого потоку полягає в тому, що програми JS були дуже обмежені в запитах:

якщо вам цікаво, чому неявний тип був включений в OAuth 2.0, пояснення просте: Однакова політика оригіналу. Тоді програмами інтерфейсу не дозволялося надсилати запити різним хостам, щоб отримати маркер доступу за допомогою коду. Сьогодні у нас є CORS (міжпохідний обмін ресурсами).

https://medium.com/securing/what-is-going-on-with-oauth-2-0-and-why-you-should-not-use-it-for-authentication-5f47597b2611