Прим. перев.: У цьому чудовому матеріалі компанії Okta просто і наочно розповідається про принципи роботи OAuth та OIDC (OpenID Connect). Ці знання будуть корисні розробникам, системним адміністраторам і навіть звичайним користувачам популярних веб-додатків, які швидше за все теж обмінюються конфіденційними даними з іншими сервісами.
У "кам'яному столітті" інтернету ділитися інформацією між сервісами було легко. Ви просто давали свій логін та пароль від одного сервісу іншому, щоб той увійшов до вашого облікового запису та отримав будь-яку необхідну йому інформацію.
«Надайте свою банківську облік». — «Обіцяємо, що з паролем та грошима все буде гаразд. Ось прям чесно-пречесно!» *хі-хі*
Жах! Ніхто і ніколи не повинен вимагати від користувача поділитися логіном та паролем, його обліковими данимиз іншим сервісом. Немає жодної гарантії, що організація, яка стоїть за цим сервісом, зберігатиме дані в безпеці і не збере більше персональної інформації, ніж потрібно. Це може здатися дикістю, але деякі програми досі застосовують подібну практику!
Сьогодні є єдиний стандарт, що дозволяє одному сервісу безпечно скористатися даними іншого. На жаль, подібні стандарти використовують масу жаргонізмів та термінів, що ускладнює їхнє розуміння. Мета цього матеріалу – за допомогою простих ілюстрацій пояснити, як вони працюють (Думаєте, що мої малюнки нагадують дитячу мазню? Ну і гаразд!).
До речі, цей посібник також доступний у форматі відео:
Пані та панове, зустрічайте: OAuth 2.0
— це стандарт безпеки, який дозволяє одній програмі отримати дозвіл на доступ до інформації в іншій програмі. Послідовність дій для надання дозволу [дозвіл] (або згоди [consent]) часто називають авторизацією [authorization] або навіть делегованою авторизацією [Delegated authorization]. За допомогою цього стандарту ви дозволяєте програмі рахувати дані або використовувати функції іншої програми від вашого імені, не повідомляючи йому свій пароль. Клас!
Як приклад уявимо, що ви виявили сайт під назвою «Невдалий каламбур дня» [Terrible Pun of the Day] і вирішили зареєструватись на ньому, щоб щодня отримувати каламбури у вигляді текстових повідомлень на телефон. Сайт вам дуже сподобався і ви вирішили поділитися ним з усіма знайомими. Адже моторошні каламбурчики подобаються всім, чи не так?
«Невдалий каламбур дня: Чули про хлопця, який втратив ліву половину тіла? Тепер він завжди правий!» (Переклад зразковий, тому що в оригіналі своя гра слів - прим. Перекл.)
Зрозуміло, що писати кожній людині із контакт-листа не варіант. І, якщо ви хоча б трохи схожі на мене, то підете на все, щоб уникнути зайвої роботи. Добре Terrible Pun of the Day може сам запросити всіх ваших друзів! Для цього лише потрібно відкрити йому доступ до електронної пошти контактів – сайт сам надішле їм запрошення (OAuth керує)!
Усі люблять каламбури! — Вже залогинилися? — Бажаєте відкрити доступ до Terrible Pun of the Day до списку контактів? - Дякую! Тепер ми щодня надсилатимемо нагадування всім, кого ви знаєте, до кінця віків! Ви найкращий друг!»
- Виберіть сервіс електронної пошти.
- У разі потреби перейдіть на сайт пошти та увійдіть до свого облікового запису.
- Дайте дозвіл на доступ до контактів Terrible Pun of the Day.
- Поверніться до сайту Terrible Pun of the Day.
Якщо ви передумаєте, програми, які використовують OAuth, також надають спосіб анулювати доступ. Вирішивши, що ви більше не бажаєте ділитися контактами з Terrible Pun of the Day, ви можете перейти на сайт пошти та видалити сайт із каламбурами зі списку авторизованих додатків.
Потік OAuth
Щойно ми пройшли через те, що зазвичай називають потоком [flow] OAuth. У нашому прикладі цей потік складається з видимих кроків, а також кількох невидимих кроків, в рамках яких два сервіси домовляються про безпечний обмін інформацією. У попередньому прикладі з Terrible Pun of the Day використовується найбільш поширений потік OAuth 2.0, відомий як потік "з кодом авторизації" [«authorization code» flow].
Перш ніж заглибитись у подробиці роботи OAuth, давайте поговоримо про значення деяких термінів:
- Власник ресурсу:
Це ви! Ви володієте своїми обліковими даними, своїми даними та керуєте всіма діями, які можуть бути зроблені з вашими обліковими записами. - Клієнт:
Додаток (наприклад, сервіс Terrible Pun of the Day), який хоче отримати доступ або виконати певні дії від імені Власник ресурсуТа. - Сервер авторизації:
Додаток, який знає Власник ресурсуТа й у якому у Власник ресурсуА вже є обліковий запис. - Сервер ресурсів:
Програмний інтерфейс програми (API) або сервіс, яким Клієнт хоче скористатися від імені Власник ресурсуТа. - URI перенаправлення:
Посилання, за яким Сервер авторизації перенаправить Власник ресурсу'а після надання дозволу Клієнт'у. Іноді її називають "Зворотним URL" ("Callback URL"). - Тип відповіді:
Тип інформації, яку очікує отримати Клієнт. Найпоширенішим Тип відповідіТому є код, тобто Клієнт розраховує отримати Код авторизації. - Сфера:
Це докладний опис дозволів, які потрібні Клієнт'у, такі як доступ до даних або виконання певних дій. - Згода:
Сервер авторизації бере Області, що запитуються КлієнтТому, і запитує у Власник ресурсуТа, чи готовий той надати Клієнт'у відповідні дозволи. - ідентифікатор клієнта:
Цей ID використовується для ідентифікації КлієнтТа на Сервер авторизаціїТе. - Клієнтська таємниця:
Це пароль, який відомий тільки КлієнтТо й Сервер авторизації'у. Він дозволяє їм конфіденційно обмінюватись інформацією. - Код авторизації:
Тимчасовий код з невеликим періодом дії, який Клієнт надає Сервер авторизації'у в обмін на Маркер доступу. - Маркер доступу:
Ключ, який клієнт буде використовувати для зв'язку з Сервер ресурсівТому. Такий собі бейдж або ключ-карта, що надає Клієнт'у дозволу на запит даних або виконання дій на Сервер ресурсівТе від вашого імені.
Примітка: іноді Authorization Server і Resource Server є одним і тим самим сервером. Однак у деяких випадках це можуть бути різні сервери, що навіть не належать до однієї організації. Наприклад, Authorization Server може бути стороннім сервісом, якому довіряє Resource Server.
Тепер, коли ми ознайомилися з основними поняттями OAuth 2.0, повернімося до нашого прикладу і детально розглянемо, що відбувається в потоці OAuth.
- Ви, Власник ресурсу, бажаєте надати сервісу Terrible Pun of the Day (Клієнт'у) доступ до своїх контактів, щоб той міг розіслати запрошення всім вашим друзям.
- Клієнт перенаправляє браузер на сторінку Сервер авторизації'а і включає запит ідентифікатор клієнта, URI перенаправлення, Тип відповіді і одне чи кілька Області (дозвіл), які йому необхідні.
- Сервер авторизації перевіряє вас, при потребі запитуючи логін та пароль.
- Сервер авторизації виводить форму Згода (підтвердження) з переліком усіх Області, запитуваних КлієнтТому. Ви погоджуєтесь або відмовляєтесь.
- Сервер авторизації перенаправляє вас на сайт КлієнтТа, використовуючи URI перенаправлення разом з Код авторизації (Кодом авторизації).
- Клієнт безпосередньо пов'язується з Сервер авторизаціїТому (в обхід браузера Власник ресурсуа) і безпечно відправляє ідентифікатор клієнта, Клієнтська таємниця и Код авторизації.
- Сервер авторизації перевіряє дані та відповідає з Маркер доступуТому (токеном доступу).
- Тепер Клієнт може використовувати Маркер доступу для надсилання запиту на Сервер ресурсів з метою одержати список контактів.
Client ID та Secret
Задовго до того, як ви дозволили Terrible Pun of the Day отримати доступ до контактів, Client та Authorization Server встановили робочі відносини. Authorization Server згенерував Client ID та Client Secret (іноді їх називають Ідентифікатор додатка и Секрет програми) і відправив їх Client'у для подальшої взаємодії в рамках OAuth.
"- Вітання! Я хотів би працювати з тобою! - Та не питання! Ось твої Client ID та Secret!»
Назва натякає, що Client Secret повинен триматися в таємниці, щоб його знали лише Client та Authorization Server. Адже саме з його допомогою Authorization Server підтверджує істинність Client'а.
Але це ще не все. Будь ласка, привітайте OpenID Connect!
OAuth 2.0 розроблений тільки для авторизації — щоб отримати доступ до даних та функцій від однієї програми до іншої. (OIDC) – це тонкий шар поверх OAuth 2.0, що додає відомості про логіну та профіль користувача, який увійшов до облікового запису. Організацію логін-сесії часто називають автентифікацією [authentication], а інформацію про користувача, що увійшов до системи (тобто Власник ресурсуТе), - особистими даними [identity]. Якщо Authorization Server підтримує OIDC, його іноді називають постачальником особистих даних [identity provider], оскільки він надає Клієнт'у інформацію про Власник ресурсуТе.
OpenID Connect дозволяє реалізовувати сценарії, коли єдиний логін можна використовувати в багатьох додатках, - цей підхід також відомий як одноразова реєстрація (SSO). Наприклад, програма може підтримувати SSO-інтеграцію з соціальними мережами, такими як Facebook або Twitter, дозволяючи користувачам використовувати обліковий запис, який вони вже мають і який вони вважають за краще використовувати.
Потік (flow) OpenID Connect має такий самий вигляд, як і у випадку OAuth. Єдина різниця в тому, що в первинному запиті конкретний scope, що використовується openid, - а Клієнт в результаті отримує як Маркер доступу, Так і ID Token.
Так само, як і в потоці OAuth, Маркер доступу в OpenID Connect - це якесь значення, не зрозуміле Клієнт'у. З точки зору КлієнтТа Маркер доступу представляє певний рядок із символів, який передається разом із кожним запитом до Сервер ресурсів'у, а той визначає, чи дійсний токен. ID Token є зовсім інше.
ID Token – це JWT
ID Token — це особливим чином відформатований рядок символів, відомий як JSON Web Token або JWT (Іноді токени JWT вимовляють як «jots»). Стороннім спостерігачам JWT може здатися незрозумілою абракадаброю, проте Клієнт може отримати з JWT різну інформацію, таку як ID, ім'я користувача, час входу в обліковий запис, термін закінчення дії ID TokenТак, наявність спроб втручання в JWT. Дані всередині ID TokenТа називаються заявками [претензії].
У випадку OIDC також є стандартний спосіб, за допомогою якого Клієнт може запросити додаткову інформацію про особу [identity] від Сервер авторизаціїТак, наприклад, адреса електронної пошти, використовуючи Маркер доступу.
Додаткові відомості про OAuth та OIDC
Отже, ми коротко розглянули принципи роботи OAuth та OIDC. Готові копнути глибше? Ось додаткові ресурси, які допоможуть дізнатися більше про OAuth 2.0 та OpenID Connect:
Як завжди, не соромтеся коментувати. Щоб бути в курсі останніх новинок, підписуйтесь на и компанії Okta для розробників!
PS від перекладача
Читайте також у нашому блозі:
- «»;
- «»;
- «»;
- «».
Джерело: habr.com