Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Web Development
Code

OAuth 2.0 - хороше, погане і жахливе

by
Length:LongLanguages:

Ukrainian (українська мова) translation by Elen (you can also view the original English article)

У світі, в якому домінують соціальні мережі, важко не натрапити на клієнтський додаток, який ви не використовували б для отримання доступу до обмежених ресурсів на іншому сервері. Наприклад, ви могли б скористатися веб-додатком (на зразок NY Times), щоб поділитися статтею з цікавими новинами на стіні Facebook, або зробити про це твіт. Або, можливо, ви використовували додаток iPhone Quora, який надає доступ до вашого профілю Facebook або Google+ і налаштовує результат відповідно до даних вашого профілю, наприклад, пропонує додати/запросити інших користувачів до Quora, базуючись на списку ваших друзів. Питання ось в чому: яким чином ці програми отримують доступ до ваших акаунтів Facebook, Twitter або Google+ і до вашої конфіденційної інформації?  Перед тим, як вони можуть це зробити, вони повинні надати певну форму облікових даних ідентифікації і дозвіл на авторизацію серверу ресурсів.


Введення до OAuth 2.0

OAuth часто називають "valet key" для веб.

Тепер було б не дуже добре ділитися обліковими даними  Facebook або Google з будь-яким стороннім клієнтським додатком, якому потрібен всього лиш список ваших друзів, оскільки так надається не тільки необмежений і небажаний доступ до вашого акаунта, але і послаблюється захист паролів. Саме тут приходить на поміч OAuth, оскільки він описує фреймворк авторизації, який може бути прийнятим без необхідності надавати паролі. Саме тому OAuth часто називають "valet key" для веб. Його можна розглядати як ключ до певних обмежених функцій на певний ліміт часу без надання повного контролю, так само як спецключ паркувальника дозволяє відвести машину на невелику відстань, блокувати багажник і бортовий сотовий телефон.

Однак, OAuth не є новою концепцією, а стандартизацією і поєднанням всього розумного з різних добре налагоджених протоколів. Також варто відзначити, що OAuth не обмежується лишень соціальними, але і надає стандартизований спосіб безпечної передачі інформації між різними додатками, які роблять доступними свої API для інших програм. OAuth 2.0 є абсолютно новим рішенням, яке не йде в порівняння зі своїм попередником. Роблячи такі заяви, давайте спочатку розглянемо базовий словник OAuth2.0 перш ніж поринути в деталі.

  • Resource Owner: суб'єкт, що здатен надавати права доступу до захищеного ресурсу. В більшості випадків це кінцевий користувач.
  • Client: запити на захищені ресурси, які робить додаток, зі сторони власника і авторизації. Це може бути серверний додаток, мобільний (рідний) або десктопний.
  • Resource Server: сервер, що здійснює хостинг захищених ресурсів, який може приймати і відповідати на запити захищених ресурсів.
  • Authorization Server: сервер, який надає дозвіл/токени доступу клієнту після успішної ідентифікації власника ресурсу та авторизації.
  • Access Token: це облікові дані, які надаються клієнтом серверу ресурсів для отримання доступу до захищених ресурсів. Зазвичай це рядок, що має певні рамки, термін дії та інші атрибути доступу, і він сам може містити інформацію про авторизацію перевіреним способом.
  • Refresh Token: хоча не керуються специфікацією, access tokens в ідеалі мають термін дії, від декількох хвилин до декількох годин. Після закінчення терміну дії токена, клієнт може запросити у сервера авторизації новий access token за допомогою оновленого токена від сервера авторизації.

Що не так в OAuth 1.0?

Основним недоліком OAuth 1.0 була складність, необхідна для реалізації специфікації.

Нічого подібного! Twitter як і раніше відмінно працює з OAuth 1.0 і тільки нещодавно почав підтримку невеликої частини специфікації 2.0. OAuth 1.0 був досить хорошим рішенням специфікації і дозволяв надійний обмін секретної інформації без накладання SSL. Причина, по якій знадобилися покращення, в основному в складності реалізації специфікації. Ось деякі області, в яких OAuth 1.0 не зумів справити добре враження:

  • Signing Every Request: потреба в генерації клієнтом підписів на кожен запит API і їх перевірка щоразу, як сервер отримує запити, стала основною проблемою для розробників, оскільки їм доводилось аналізувати, кодувати і сортувати параметри перед тим, як робити запит. OAuth 2.0 вилучив цю незручність і тепер просто відсилає токени через SSL, вирішуючи цю ж проблему на рівні мережі. З OAuth 2.0 немає потреби в підписах.
  • Addressing Native Applications: З розвитком рідних додатків для мобільних пристроїв, орієнтований на веб OAuth 1.0 здається нездатним в використанні агентів на зразок веб-браузерів. OAuth 2.0 розмістив більше потоків, які є спеціальними для рідних додатків.
  • Clear Separation of Roles: OAuth 2.0 в значній мірі забезпечує потребу в розподілі ролей в ідентифікації і авторизації клієнта сервером, а також в обробці сервером запитів API для доступу до обмежених ресурсів.

Детальніше про OAuth 2.0

Перед ініціюванням протоколу, клієнт повинен зареєструватися на авторизаційному сервері надавши свій тип клієнта, перенаправлений URL (куди він хоче, щоб сервер авторизації переадресовував його після того, як власник ресурсу надасть або відхилить право доступу) і будь-яку іншу інформацію, яку запросить сервер, і взамін він надасть ідентифікатор клієнта (client_id) і client secret (client_secret). Цей процес відомий як реєстрація клієнта. Після реєстрації, клієнт може прийняти один з наступних потоків, щоб взаємодіяти з сервером.

Різні потоки OAuth

OAuth 2.0 приносить близько п'яти нових потоків і надає розробникам гнучкості в реалізації будь-якого з них, залежно від типу залученого клієнта.

  • User-Agent Flow: підходить для клієнтів, як правило впроваджених в user-agent (наприклад, клієнтів, що працюють всередині веб-браузера) за допомогою мови написання скриптів, наприклад, JavaScript. Зазвичай використовується рідними додатками для мобільних пристроїв чи десктоп за допомогою вбудованого або зовнішнього браузера в якості user-agent для авторизації; використовує авторизацію Implicit Grant.
  • Web Server Flow: використовує дозвіл Authorization Code і є потоком на основі редиректу, який вимагає взаємодії з user-agent кінцевого користувача. Таким чином він є найбільш підходящим для клієнтів, які є частиною додатків, які базуються на веб-сервері і до яких, як правило, отримують доступ через веб-браузер.
  • Username and Password Flow: використовується тільки при високому рівні довіри між клієнтом і власником ресурсу, а також коли інші потоки недоступні, оскільки це підрозуміває передачу облікових даних власника ресурсу. Прикладом клієнта може бути операційна система пристрою або додаток з високим рівнем пріоритету. Це також може бути використано для міграції існуючих клієнтів за допомогою HTTP Basic або схем Digest Authentication до OAuth шляхом конвертації збережених облікових даних в токен доступу.
  • Assertion Flow: ваш клієнт може представити твердження, таке як SAML Assertion, серверу авторизації взамін на токен доступу.
  • Client Credentials Flow: OAuth зазвичай використовується для делегованого доступу, проте є випадки, коли клієнт володіє ресурсом або вже має дозвіл на делегований доступ за межами типового потоку OAuth. В такому випадку ви просто обмінюєте облікові дані клієнта на токен доступу.

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

Web Server Flow

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

webserverflow

Автентифікація і авторизація клієнта

Клієнт від імені власника ресурсу ініціює потік шляхом редиректу на кінцеву точку авторизації з параметром response_type в якості code, ідентифікатором клієнта, який отримується під час реєстрації клієнта, URL перенаправлення, діапазон (додатково) та держава (якщо є). Щоб ви могли зрозуміти, як це працює, нижче представлено скріншот: вигляд типового запиту/відповіді:

step1Request

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

allowAccess

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

step1Response

Заміна коду авторизації на токен

Далі клієнт робить пост іншої кінцевої точки авторизації і надсилає код авторизації, отриманий в попередніх кроках, а також URL редиректа, ідентифікатор клієнта і secret, отриманий при реєстрації клієнта, параметр grant_type повинен бути встановлений як authorization_code.

step2Request

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

step2Response

Запит на обмежені ресурси за допомогою токенів доступу

Клієнт тепер може користуватися APIs, який надано завдяки реалізації, може запросити у сервера ресурсів обмежені дані, передавши токен доступу в заголовку запиту авторизації. Приклад запиту CURL до Google's Blogger API, щоб отримати блог, наданий йому ідентифікатор, матиме наступний вигляд:

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

step3Request

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

step3Response

Ці приклади є люб'язністю OAuth2.0 Playground і тим, як Google зазвичай реалізує їх специфікацію. При використанні одного і того ж потоку різними провайдерами (на зразок Facebook чи Salesforce) можуть спостерігатися деякі відмінності. І саме тут з'являються питання функціональної сумісності, про що ми поговоримо трохи пізніше.

Оновлення токена доступу

Хоча це не передбачено специфікацією, проте, як правило, токени доступу недовговічні і мають термін закінчення дії. Тому, після закінчення останнього, клієнт надсилає оновлення токена на сервер авторизації разом з його ідентифікатором і secret, а також параметр grant_type як refresh_token.

step4Request

Далі сервер авторизації відповідає на нове значення токена доступу.

step4Response

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


Що не так з OAuth 2.0?

Хороша сторона

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

Погана сторона

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

Недопрацювання в специфікації OAuth 2.0, швидше за все, дадуть широкий спектр незбалансованих реалізацій.

  • Interoperability: додавання надто багатьох точок розширення в специфікацію призвело до функціональної несумісності. Це означає, що ви не можете сподіватися написати загальний фрагмент коду, який використовує Endpoint Discovery, щоб знати про кінцеві точки, надані різними реалізаціями, і взаємодіяти з ними. скоріше вам доведеться написати окремі фрагменти коду для Facebook, Google, Salesforce тощо. Цей недолік відзначено навіть в специфікації як застереження.
  • Short Lived Tokens: специфікація не визначає термін дії та обсяг випущених токенів. Імплементація може цілком мати токен з необмеженим терміном дії. Хоча більшість імплементацій забезпечують нас токенами доступу з короткими термінами дії і оновленим токеном, який можна використовувати для отримання нового токена доступу.
  • Security: специфікація всього лиш "рекомендує" використовувати SSL/TLS при відправленні токенів незашифрованим текстом по проводу. Хоча кожна суттєва реалізація вимагає наявності захищених кінцевих точок авторизації, а також вимагає, щоб клієнт мав безпечну URL-адресу для редиректу, інакше злочинцю буде надто легко прослухати повідомлення та розшифрувати токени.

Найгірший аспект

Для того, щоб нарешті випустити специфікацію, знадобився 31 варіант версії, а також Eran Hammer, провідному розробнику, довелося покинути комітет. Eran назвав специфікацію "поганим протоколом і смертельним випадком для тисячі скорочень", після чого спалахнула суперечка. Відповідно до його заяви, використання bearer tokens (відправлення токенів через SSL без їх реєстрації чи будь-якої іншої перевірки) через користувача підписами (або MAC-Tokens), які використовувались в OAuth 1.0 для реєстрації запиту, є поганим кроком і результатом розбіжностей в інтересах між веб-спільнотою і підприємцями.


Останні зауваження

Специфікація без сумніву залишає відкритими багато питань, що призводить до імплементацій, які представляють свої параметри, окрім тих, які вже визначає специфікація, це гарантує, що реалізації від різних постачальників не може взаємодіяти одна з одною. Але зі зростанням популярності і ступеню адаптації цього фреймворка, враховуючи великих гравців (Google, Twitter, Facebook, Salesforce, Foursquare, Github та ін.) імплементацію і використання в зручний для них спосіб, OAuth - далеко не невдача. Фактично, будь-який веб-додаток, який планує розкривати свої API іншим веб-додаткам, повинен підтримувати певну форму аутентифікації та авторизації, і саме тут OAuth дуже доречний.

Прочитайте в майбутньому

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.