OAuth 2.0 & OIDC Vocabulary: 25 Security Terms Every Developer Needs (англійською)
Типи дозволів OAuth 2. 0, PKCE, токени OIDC, обсяги, заявки і словник ідентифікаційних даних для інженерів сервера і безпеки.
Безпека та ідентичність є двома з найбільш комунікаційно-важких областей в інженерії програмного забезпечення. Коли ви приєднаєтеся до команди, що працює над розпізнаванням, розпізнаванням API або єдиним входом, ви негайно почуєте такі терміни, як « потік коду аутентифікації », « PKCE », « кінцева точка інтроспекції » і « ідентифікаційний токен ». Неправильне використання словника — або поєднання OAuth і OIDC — може призвести до реальних непорозумінь у дискусіях щодо архітектури та перегляду коду. Цей посібник містить 25 термінів, які вам слід знати, щоб впевнено говорити про сучасні засоби ідентифікації та авторизації.
Основні концепції OAuth 2.0
** OAuth 2. 0 ** — це відкрита система авторизації, яка надає сторонній програмі змогу отримати обмежений доступ до служби від імені користувача, без того, щоб користувач ділився своїм паролем. У ній визначено набір ролей, типів токенів і потоків (названих типами надання) для безпечного виконання цих дій.
«Ми використовуємо OAuth 2.0, тому мобільне застосування може отримати доступ до API без зберігання даних користувача» ОАут обробляє авторизацію, а не автентифікацію — це важлива відмінність
** Сервер авторизації ** — це компонент, який відповідає за видачу токенів. Він автентифікує користувача (або клієнта), перевіряє запит і роздає токени доступу, токени оновлення, а у потоках OIDC — токени ідентифікації.
“Авторизаційний сервер працює на порту 8080 в нашому локальному стеку. Вам потрібно буде зареєструвати ваш URI перенаправлення там» «Ми оцінюємо, чи використовувати Keycloak або побудувати наш власний сервер авторизації»
** Сервер ресурсів ** — це API або служба, яка зберігає захищені дані. Цей інструмент приймає токени доступу, перевіряє їх і повертає запит на ресурс, якщо токени є коректними і мають відповідні права доступу.
«Ресурсний сервер повинен перевіряти підпис токена на кожному запиті — він не повинен сліпо довіряти токенам» «Ми розділили наш моноліт, тому тепер кожна мікросервіс діє як власний ресурсний сервер»
** Клієнт ** у термінології OAuth — це програма, яка надсилає запит на доступ до ресурсу від імені користувача. Клієнти бувають двох типів:
- ** Публічний клієнт ** — не може безпечно зберігати секрет (наприклад, односторінкова програма або мобільна програма, запущена на пристрої користувача).
- Confidential client — працює на стороні сервера і може безпечно зберігати секрет клієнта (наприклад, backend Node.js або Django).
“Оскільки React-програма є публічним клієнтом, ми повинні використовувати PKCE — ми не можемо вбудовувати клієнтський секрет у фронтенд.” «Зареєструвати службу як конфіденційного клієнта і зберігати секрет в Vault, а не в репо.»
Типи і види робіт
** Тип надання ** описує механізм, за допомогою якого клієнт отримує токени доступу. OAuth 2.0 визначає декілька типів дозволів для різних випадків використання.
** Надання коду авторизації ** — це рекомендований потік для програм, які діють від імені користувача. Користувач входить на сервер авторизації, який перенаправляє назад до клієнта з короткочасним кодом. Клієнт обмінює цей код на токени в кінцевій точці зворотного каналу, утримуючи токени від панелі URL браузера.
“Використовуйте поток авторизаційного коду - ніколи не неявний потік. Неявний потік є застарілим з хорошої причини» «Код є одноразовим і закінчується через 60 секунд, тому обміняйте його негайно»
** Надання уповноважень клієнта ** використовується для обміну даними між машинами (M2M), у якому не бере участі людина. Клієнт здійснює розпізнавання за допомогою власних даних реєстрації і отримує токен доступу, який представляє його самого, а не користувача.
“Пакетне завдання використовує уповноваження клієнта для виклику API конвеєра даних. Тут немає контексту користувача» «Упевніться, що обліковий запис служби має тільки ті обсяги, які йому дійсно потрібні — тут також застосовуються найменші привілеї»
Device Flow (також називається Device Authorisation Grant) призначено для пристроїв з обмеженими можливостями вводу — розумних телевізорів, інструментів CLI, пристроїв IoT. Пристрій відображає короткий код, користувач завершує авторизацію на окремому пристрої (наприклад, на телефоні), а початковий пристрій опитує, поки не отримає токен.
«Ми реалізували поток пристроїв для інструменту CLI, щоб інженери могли автентифікуватися без вставлення токенів вручну» “Пристрій запитує кожні п’ять секунд і код закінчується через десять хвилин.”
** PKCE ** (Proof Key for Code Exchange, вимовляється « pixie ») — це розширення безпеки потоку кодів авторизації. Клієнт створює випадковий секрет, який називається ** перевірка коду **, гешує його, щоб створити ** виклик коду **, і надсилає виклик з початковим запитом. Під час обміну коду на токени, клієнт доводить, що він володіє початковим перевіряючим. Це запобігає атакам перехоплення авторизаційного коду, що є критичним для публічних клієнтів.
«PKCE тепер обов’язковий для всіх громадських клієнтів. Це не є необмеженим» Метод виклику коду повинен бути S256 — простий тільки для застарілих клієнтів, які не можуть робити гешування
Складові і їх структура
** Токен доступу ** — це уповноваження, які використовуються для виклику захищеного ресурсу. Це, як правило, короткочасний рядок (часто JWT), який сервер ресурсів перевіряє при кожному запиті. Його тривалість життя навмисно коротка — зазвичай від 5 до 60 хвилин — щоб обмежити шкоду, якщо вона витікає.
«Передавати токен доступу в заголовку Authorization як токен Bearer.» «Страта чинності токена доступу через 30 секунд — клієнт повинен використовувати токен оновлення, щоб отримати новий»
** Токен оновлення ** — це довговічний унікальний ідентифікатор, який використовується для отримання нових токенів доступу без необхідності повторного входу користувача у систему. Цей обмін відбувається безпосередньо з сервером авторизації, він ніколи не надсилається на сервери ресурсів.
«Зберігати оновлювальні токени безпечно — в HTTP-cookie або серверній сесії, ніколи в localStorage.» «Освіжити токени обертання ввімкнено, так що кожен раз, коли ви використовуєте токени оновлення, ви отримаєте новий назад.»
** JWT ** (JSON Web Token, вимовляється « jot ») — це компактний формат токенів, безпечний для URL, який широко використовується для токенів доступу і ідентифікаційних токенів. JWT складається з трьох частин, закодованих у base64url і відокремлених крапками:
- ** Заголовок ** — метадані щодо токена, включаючи алгоритм підписування (наприклад, Р-256 (рос.)
- ** Утримувана інформація ** — заявки: дані про суб’ єкта, видавця, термін дії, області дії і будь- які нетипові поля.
- ** Підпис ** — криптографічне значення, яке надає можливість отримувачам перевірити, що токеном не було зловжито.
Вставте токен в jwt.io і перевірте твердження про термін дії — виглядає, що він вже закінчився «Ми використовуємо RS256, тому ресурсний сервер може перевірити, використовуючи відкритий ключ, без виклику сервера авторизації»
О. І. Степаненко, опис і описи
** OIDC ** (OpenID Connect) — це рівень ідентифікації, побудований на основі OAuth 2. 0. У той час як OAuth 2.0 обробляє авторизацію (що ви можете робити), OIDC обробляє автентифікацію (хто ви). Цей параметр додає стандартизований ідентифікаційний токен і кінцеву точку UserInfo до потоків OAuth.
«Ми потребуємо OIDC, а не тільки OAuth — ми хочемо знати, хто користувач, а не тільки те, що вони мають доступ» «OIDC є OAuth 2.0 плюс рівень ідентичності. Розгляньте OAuth як основу»
** ID token ** — це JWT, виданий надавальником OIDC, який містить інформацію про ідентифікацію розпізнаного користувача. Цей символ призначено для * клієнта *, а не для сервера ресурсів, і його не слід використовувати як токен доступу для виклику API.
ID-токен містить ім’я користувача та електронну пошту — використовуйте його для заповнення інтерфейсу профілю “Не відправляйте ідентифікаційний токен до вашого API. Это не для этого. Використовуйте токен доступу.”
** Область дії ** — це механізм для запитів на певні права доступу. Клієнт декларує, які області обробки йому потрібні у запиту на авторизацію. Поширені обсяги OIDC включають openid (вимагаються для OIDC), profile, email, і offline_access (для обновлення токенів).
«Додати
offline_accessдо запиту на обсяг, якщо ви хочете оновити токен» «Користувач погодився тільки на обсягread:messages— цьому клієнту не дозволено нічого вилучати»
** Заява ** є парою ключ- значення всередині корисного навантаження JWT. Стандартні твердження включають sub (суб’єкт/ID користувача), iss (видавач), exp (закінчення терміну дії), iat (видано в) і aud (аудиторія). Нетипові заявки містять дані, специфічні для програми, такі як ролі або ідентифікатори користувачів.
«
subпретензія є канонічним ідентифікатором користувача — використовуйте його для посилання на ваші власні записи користувача, а не електронну пошту.» «Ми додаємо нетиповуtenant_idпретензію до токена, щоб послуги знали, до якої організації належить користувач»
** Інтроспекція ** — це кінцева точка, визначена у RFC 7662, яка надає змогу ресурсному серверу запитувати сервер авторизації, щоб перевірити, чи активний токен, і отримати його метадані. Це альтернатива локальної перевірки JWT.
«Старі сервіси, які не можуть перевірити JWTs локально, викликають кінцеву точку інтроспекції на кожному запиті» «Інтроспективність додає затримку і навантаження на сервер авторизації — віддавайте перевагу локальній перевірці, де це можливо»
** Відкликання токена ** — це можливість скасувати чинність токена до його природного закінчення. RFC 7009 визначає кінцеву точку відкликання. Це важливо для потоків виходу і для реагування на інциденти з безпекою.
«Коли користувач виходить, викликайте кінцеву точку відкликання, щоб негайно анульувати токен оновлення» “Токени доступу важко відкликати, тому що вони перевіряються локально. Тому важливо, щоб вони були короткочасними»
Як використовувати їх у розмові
Зрозуміти терміни - це перший крок - використовувати їх природно в обговореннях команди - це мета. Ось чотири сценарії, з якими ви, ймовірно, зіткнетеся.
В обзоре безопасности: “Мобільна програма є публічним клієнтом, тому ми не можемо використовувати клієнтські дані. Нам потрібен поток авторизаційного коду з PKCE і короткочасним токеном доступу. Поворот токенів оновлення повинен бути ввімкненим, і ми повинні відкликати токени при виході»
** У обговоренні архітектури: ** « Служба А має викликати службу Б. Нет никакого пользователя, поэтому мы используем учетные данные клиента. Служба B діє як сервер ресурсів і перевіряє JWT локально за допомогою відкритого ключа сервера авторизації. Не потрібно інтроспекції»
В обзоре кода: “Вы сохраняете ID-токен в localStorage — не делайте этого. Зберігати токен доступу у пам’ яті і токен оновлення у куці, призначеній тільки для HTTP. Також перевірте aud заяву на токені доступу, щоб переконатися, що він призначений для цього ресурсного сервера
В одном случае после смерти: “В файле журнала был обнаружен токен обновления. Ми негайно викликали кінцеву точку відкликання. Оскільки токени доступу мають короткий термін дії (15 хвилин), вікно експозиції було обмежено. В подальшому, ми фільтруємо токени з журналів на рівні середовища.»
Краткий справочник
| Term | What it is | Key point |
|---|---|---|
| OAuth 2.0 | Authorisation framework | Handles what an app can do, not who the user is |
| OIDC | Identity layer on OAuth 2.0 | Adds authentication — who the user is |
| Access token | Credential for API calls | Short-lived; sent in Authorization header |
| Refresh token | Credential for renewing access tokens | Long-lived; never sent to resource servers |
| ID token | JWT with user identity | For the client only; not for API authorisation |
| JWT | Token format (header.payload.signature) | Verified locally using signing key |
| PKCE | Code exchange security extension | Required for public clients |
| Scope | Requested permissions | Declared at authorisation request time |
| Claim | Key-value pair inside a JWT | sub, exp, aud are standard claims |
| Introspection | Server-side token validation endpoint | Use when local JWT validation is not possible |