У світі, де все домінують соціальні медіа, важко не піддатися спокусі встановити клієнтське додаток, за допомогою якого ви змогли б отримати доступ до обмежених ресурсів на іншому сервері.
Наприклад, ви могли б використовувати веб-додаток (скажімо, від Нью-Йорк Таймс) для імпорту цікавих статей у ваш Facebook або Twitter. Або ви могли б використовувати додаток для iPhone Quora, за допомогою якого користувачі можуть отримувати доступ до дошки ваших новин на тому ж Facebook або Google+.
Його можна налаштувати з урахуванням даних вашого профілю: додавати / запрошувати до Quora користувачів, що знаходяться у вашому списку друзів. Питання в тому, як ці програми отримують доступ до вашого аккаунту Facebook, Twitter або Google+, а особливо до конфіденційної інформації?
Перш ніж додаток зможе це зробити, воно повинне надати якусь форму грантів аутентифікації та авторизації ресурсів сервера.
Введення в OAuth 2.0
На сьогоднішній день це дійсно круто мати можливість поділитися своїми записами із Facebook або Google+ з будь-яким стороннім клієнтським додатком. Причому зробити так, щоб ваші записи були доступні тільки вашим друзям, так як сервіс не тільки обмежує небажаний доступ, але і відстежує користувачів, грунтуючись на логіни і паролі.
Тут в гру вступає OAuth, який є фреймворком для віддаленого делегування доступів / авторизації, який можна використовувати без необхідності додаткового обміну паролями. З цієї причини OAuth часто називають камердинерской зв’язкою ключів від Інтернету.
Його можна розглядати як особливий ключ, який дозволяє отримати доступ до обмеженого набору функцій, протягом певного періоду часу, при цьому передаючи додатком повний контроль.
Подібно до того, як паркувальнику дозволяється припаркувати машину біля ресторану, але при цьому йому не дозволено їздити на ній по місту, користуватися вбудованим мобільним телефоном або іншими функціями.
Тим не менш, OAuth не базується на якійсь абсолютно нової технології, але розумно використовує комбінацію стандартних, давно встановлених протоколів.
Також варто відзначити, що OAuth не обмежується тільки соціальними медіа — він забезпечує формалізований надійний спосіб обміну інформацією між різними видами додатків, які надають обмежений доступ до своїх функцій.
OAuth 2.0 має абсолютно нову ідеологію і підтримує зворотну сумісність з додатками попередніх версій. Перш ніж пояснити, у чому його переваги, я хотів би спочатку, розглянемо визначення деяких понять і функцій, якими оперує, OAuth2.0:
- Ресурс власника: додаток, яке здатне надавати доступ до захищеного ресурсу. Як правило, кінцевим користувачам;
- Клієнт: додаток, яке надсилає запити до захищеного ресурсу від імені його власника і з його дозволу. Це можуть бути серверні, мобільні або настільні додатки;
- Сервер ресурсу: сервер захищеного ресурсу, здатний приймати і відповідати на запити до ресурсу;
- Авторизація на сервері: видача сервером клієнту грантів / маркерів доступу після успішної аутентифікації ресурс власника та отримання від нього дозволу;
- Маркер доступу: маркери доступу до облікових даних, які клієнт надає сервера ресурсу для отримання можливості використовувати захищені ресурси. Зазвичай це рядок параметрів, що визначають межі доступу, тривалості сесії та інші атрибути. Вона також може містити дані для проходження авторизації в тій чи іншій формі;
- Оновлення маркера: Хоча це і не передбачено за замовчуванням, маркери доступу в ідеалі повинні мати термін дії (сесії), який може становити від декількох хвилин до декількох годин. Як тільки час дії маркера доступу минув, клієнт може запросити сервер авторизації та видачу нового маркера доступу з допомогою відновлення маркера.
У чому була проблема OAuth 1.0?
Головним недоліком OAuth 1.0 була занадто велика складність даної версії.
Насправді ніяких особливих проблем не було! Twitter, як і раніше відмінно працює з OAuth 1.0 і просто додав ще і підтримку версії 2.0. OAuth 1.0 був добре продуманої версією фреймворку, яка забезпечувала надійний обмін закритою інформацією, і це робило можливим обмін секретною інформацією без з’єднання SSL.
Причина, чому знадобилася розробка оновлення полягає в основному в складності, з якою була пов’язана робота версії. Нижче наведені деякі сфери, де OAuth 1.0 не відповідав усім сучасним вимогам:
- Підпис кожного запиту: Наявність клієнтів, які генерували підпису кожного запиту додатків і перевіряли на сервері кожен запит. Це стало серйозним ударом для розробників, які повинні були розбирати, кодувати і сортувати параметри, перш ніж відправити запит.
У OAuth 2.0 вдалося обійти цю складність. Просто відсилаючи маркери по SSL і вирішуючи цю задачу на мережному рівні. OAuth 2.0 не потрібно ніяких сигнатур;
- Переадресація вбудованих додатків: З розвитком вбудованих додатків браузерів для мобільних пристроїв веб-потоки OAuth 1.0 виявилися просто неефективні.
Так, для них обов’язково використання таких агентів як сам інтернет-браузер. У OAuth 2.0 потоки були переорієнтовані саме на роботу з вбудованими додатками;
- Чіткий розподіл ролей: OAuth 2.0 забезпечує настільки необхідну поділ ролей для сервера авторизації, аутентифікації та авторизації клієнта, з допомогою чого сервер ресурсу може обробляти запити додатків на надання доступу до закритих ресурсів.
OAuth 2.0 в деталях
Перед ініціалізацією протоколу клієнт повинен зареєструватися на сервері авторизації, надаючи інформацію про тип клієнта, URL-адресу перенаправлення (куди він повинен бути перенаправлений для авторизації, після того, як сервер ресурсу видасть йому грант або ж відмовить у доступі) і будь-яку іншу інформацію, необхідну сервера.
Натомість він отримує ідентифікатор клієнта (client_id) і секретний код клієнта (client_secret). Цей процес називається реєстрацією клієнта. Після реєстрації клієнт може взаємодіяти з сервером по одному з таких потоків.
Можливі потоки OAuth
OAuth 2.0 додає в таблицю близько п’яти нових потоків, що забезпечує розробникам гнучкість в реалізації рішень. Вони можуть використовувати будь-який з них, в залежності від типу клієнта, задіяного в процесі обміну даними:
- Потік користувач-агент: Як правило, підходить для клієнтів, реалізованих на базі програм-агентів користувачів (наприклад, клієнти, що запускаються всередині оболонки браузера) з допомогою мов сценаріїв, таких як JavaScript і інші.
В основному використовується вбудованими додатками для мобільних пристроїв і операційних систем. В якості агента користувача авторизації використовує вбудований або зовнішній браузер, який підтримує Implicit Grant авторизацію;
- Потік веб-сервера: Забезпечує використання гранту коду авторизації. Він являє собою потік, заснований на принципі перенаправлень, для якого необхідно взаємодія з агентом кінцевого користувача.
Таким чином, даний потік підходить для клієнтів, які є частиною додатків, що працюють на сервері, доступ до яких, як правило, здійснюється через веб-браузер;
- Потік імен користувачів і паролів: Використовується тільки у випадку, коли наявна висока ступінь довіри між клієнтом і ресурсом власника, в той час як інші потоки не в змозі вирішити поставлену задачу. Він припускає передачу клієнту повноважень власника ресурсу.
В якості прикладу клієнта для такого роду взаємодій можна привести операційну систему пристрої або додаток з широкими правами доступу. Він також може використовуватися для перенесення існуючих клієнтів через протокол HTTP або схеми Digest Authentication в OAuth шляхом перетворення записаних облікових даних маркер доступу;
- Потік твердження: Ваш клієнт може видавати твердження, наприклад SAML затвердження, в обмін на наданий маркер доступу;
- Потік ідентифікаційної інформації клієнта: OAuth використовується в основному для делегованого доступу, але бувають випадки, коли клієнт одночасно є власником ресурсу або вже йому були надані права доступу понад звичайних потоків OAuth . Тут просто відбувається обмін наданих ідентифікаційних даних клієнта на маркер доступу.
Детальний розгляд кожного з перерахованих потоків виходить за рамки даної статті, і я б рекомендував вам для отримання більш детальної інформації по цим потокам ознайомитися зі специфікаціями.
Але щоб дати вам більше базових знань для їх вивчення, давайте розглянемо більш глибоко один з найбільш часто використовуваних потоків: потік веб-сервера.
Потік веб-сервера
Так як даний потік використовує перенаправлення, клієнт повинен мати можливість взаємодіяти з агентом користувача власника ресурсу (в якості якого в більшості випадків виступає веб-браузер) і, отже, він підходить для роботи з веб-додатками.
На діаграмі нижче, загалом, показано, як кінцевий користувач (або власник ресурсу) використовує клієнтське додаток (в даному випадку на основі додатка сервера) для аутентифікації та авторизації на сервері, для того, щоб отримати доступ до захищених ресурсів.
Аутентифікація і авторизація клієнта
Клієнт від імені власника ресурсу ініціює потік шляхом перенаправлення до кінцевої точки авторизації, використовуючи при цьому: параметр response_type як код; ідентифікатор клієнта, який був отриманий в процесі реєстрації клієнта; URL перенаправлення; запитаний обсяг повноважень (опціонально) і поточний стан (якщо потрібно).
Щоб отримати більш наочне уявлення про те, як здійснюється весь процес, на скріншоті нижче графічно представлено, як буде виглядати обробка стандартного запиту / відповіді:
Через веб-інтерфейс власнику ресурсу зазвичай представляється наступна панель, в якій він може упевнитися в тому, що всі дозволи клієнтським додатком отримані, і воно може використовувати закриті ресурси від імені їх власника.
Якщо, клієнтом отримані гранти власника ресурсу доступу, сервер авторизації перенаправляє агент користувача назад клієнтові за допомогою параметрів перенаправлення, які були надані раніше, разом з кодом авторизації.
Як це показано на малюнку нижче:
Обмін коду авторизації на маркер
Після цього клієнт переходить на наступний етап і відправляє код авторизації, отриманий на попередньому етапі разом з URL-адресою перенаправлення, ідентифікатором клієнта, секретним кодом, отриманим в процесі реєстрації клієнта, і параметром grant_type, який повинен бути встановлений як authorization_code.
Потім сервер перевіряє код авторизації та URL-адресу перенаправлення, так само, як на попередньому етапі. У разі успішного проходження перевірки, сервер надсилає відповідь разом з маркером доступу і, опціонально, з оновленим маркером.
Запит на отримання доступу до закритих ресурсів з використанням маркерів доступу.
Тепер клієнт може використовувати додатки, що надаються сервером, а також направляти запити на використання закритих ресурсів.
При цьому в заголовку Authorization запиту додається маркер доступу. В якості прикладу CURL-запиту на отримання в блозі даних з Google Blogger API з урахуванням ідентифікатора може послужити наступний код:
$ curl https://www.googleapis.com/blogger/v3/blogs/5223788876950011016 -H ‘Authorization: OAuth ya29.AHES6ZRTj1GNxAby81Es-p_YPWWNBAFRvBYVsYj2HZJfJHU’
Зверніть увагу, що маркер доступу доданий в якості заголовка Authorization в запиті, а також виділено одинарними лапками, так як маркер може містити спеціальні символи.
Майте на увазі, що виділення маркера доступу потрібно тільки при двосторонньому взаємодії. В результаті чого відправляється запит:
Потім сервер ресурсу перевіряє передані дані (маркер доступу) і у разі успішної перевірки, надсилає необхідну інформацію.
Ці приклади ілюструють принципи роботи OAuth2.0 Playground. Подібним чином, як правило, реалізується взаємодія даній версії з Google.
Трохи по-іншому взаємодія може відбуватися при зверненні до інших сервісів (наприклад, Facebook або Salesforce), що пов’язано з проблемами слабкої сумісності кінцевих рішень, які ми обговоримо трохи пізніше.
Оновлення маркера доступу
Хоча це і не передбачено за замовчуванням, але, як правило, маркери доступу мають обмежений термін дії. Тому, коли період дії маркера закінчився, клієнт відсилає до сервера авторизації запит на оновлення маркера.
До нього додаються ідентифікатор клієнта і секретний код, а також параметр grant_type як refresh_token.
У відповідь сервер авторизації відправляє пакет з новим значенням маркера.
Не дивлячись на те, що механізм відкликання оновленого маркера і існує, як правило, він зберігається вічно, а тому повинен бути захищений, точно так само, як і всі секретні дані.
Так в чому ж проблема OAuth 2.0?
Хороший (позитивний момент).
Судячи по швидкості, з якою був випущений OAuth 2.0, це, безумовно, крок вперед у порівнянні з його попередником. Відомі випадки, коли члени співтовариства розробників мали деякі труднощі при впровадженні версії 1.0. OAuth 2.0 надає кілька нових видів грантів, які можуть бути використані для реалізації різних завдань користувачів, пов’язаних з вбудованими додатками, однак головним плюсом цієї версії фреймворку є його простота порівнянні з версією 1.0.
Поганий (негативні моменти).
Неотточенние елементи версії OAuth 2.0 можуть призвести до того, що велика кількість рішень по його впровадженню будуть несумісні один з одним.
У даній версії залишаються кілька недопрацьованих моментів, пов’язаних з тим, що вона не може правильно визначити кілька необхідних компонентів або взаємодію з ними ще не прописано:
- Взаємодія: Додавання занадто великої кількості оновлень і розширень призвело до того, що деякі компоненти просто несумісні один з одним. Це означає, що ви не можете написати універсальний код з використанням Endpoint Discovery, і бути впевненим, що він підійде для взаємодії з різними сервісами.
Насправді вам доведеться писати окремі фрагменти коду під Facebook, Google, Salesforce і так далі. Цей момент навіть визнаний у специфікації версії;
- Обмежений термін дії маркерів: Дана версія фреймворку не забезпечує безстроковий період дії всіх маркерів, які були видані.
Хоча в залежності від конкретних практичних рішень така можливість існує. У більшості ж випадків надається короткостроковий маркер доступу з можливістю його оновлення за запитом;
- Безпека: У даній версії всього лише «рекомендовано» використання протоколів SSL / TLS при відправці маркерів у вигляді звичайного тексту по мережі.
Хоча, для кожного великого рішення обов’язково мати безпечні кінцеві точки авторизації, наявність для клієнта безпечного URL перенаправлення. В іншому випадку зловмисникам буде занадто просто перехопити повідомлення і розшифрувати маркери.
Злий…
Було перепробовано близько 31 чорновій версії фреймворку, в ході чого був зміщений провідний автор / розробник Еран Хаммер, перш ніж нова версія, нарешті, побачила світ. Еран наполягав на тому, що в даній специфікації реалізований «поганий протокол і вона нежиттєздатна внаслідок ще тисячі огріх».
За його словами, використання маркерів «на пред’явника» (відправка маркерів по SSL без підпису або будь-який інший верифікації) замість сигнатур користувачів (або MAC-маркерів), які використовувалися в OAuth 1.0 – це невдале рішення. Це, за його словами, результат переваги інтересів підприємців інтересам веб-спільноти.
Кілька зауважень висновок
Дана версія, безумовно, залишає відкритими багато аспектів, і в залежності від завдань конкретних прикладних застосувань їх автори встановлюють свої власні параметри, на додаток до того, що прописано у фреймворку.
Що не гарантує того, що практичні рішення від різних провайдерів будуть нормально взаємодіяти один з одним.
Однак з кожним новим впровадженням для великих сервісів (Google, Twitter, Facebook, Salesforce, Foursquare, Github і т. д.) OAuth стає все популярнішим.
Насправді, будь-який веб-сервіс, який планує надавати доступ до своїх програм іншим сервісам, повинен підтримувати якусь форму аутентифікації та авторизації. І OAuth, відповідає цим вимогам.
Переклад статті «OAuth 2.0 – The Good,The Bad & The Ugly» був підготовлений дружною командою проекту Сайтостроение від А до Я.
