Англійська для потоків OAuth2

« OAuth » використовується як загальна назва для входу, автентифікації та авторизації, але це три різні концепції, і OAuth2 сама по собі є сімейством різних потоків для різних типів клієнтів — точний словник тут запобігає справді небезпечним реалізаціям, а не просто заплутаним розмовам.

Ключовий словник

** Потік коду авторизації ** — тип надання OAuth2, за якого клієнт перенаправляє користувача на сервер авторизації, отримує короткочасний код при перенаправленні назад і обмінює цей код на сервері на токени, утримуючи токени поза адресою URL і історією переглядача. “Ми використовуємо потік коду авторизації з PKCE для веб- програми, тому фактичний токен доступу ніколи не буде відкрито в адресі URL перенаправлення, яка може опинитися в історії переглядача або заголовках посилання.”

** Токен доступу ** — це уповноваження, яке клієнт надає API, щоб довести, що він має право дій на ресурсі, зазвичай, це короткочасне уповноваження, яке має обмеження за певними правами.

• “Страта чинності токена доступу настає через п’ ятнадцять хвилин, отже клієнту слід оновити його перед тим, як здійснювати довготривалі виклики API.” *

** Token оновлення ** — довговічні уповноваження, які використовуються для отримання нового токена доступу без необхідності повторного входу користувача у систему, які видаються разом з токеном доступу у потоках, які підтримують цей токен. “Ми зберігаємо токен оновлення безпечно на сервері і використовуємо його для тихого виготовлення нових токенів доступу, тому сеанс користувача не закінчується кожні п’ятнадцять хвилин.”

** Обсяг** — рядок, що визначає певний запит на право доступу ( read:orders, write:profile ), що дозволяє клієнту запитувати лише той доступ, який йому дійсно потрібен, а не надавати повний доступ. “Інтеграція запитала тільки обсяг read:orders, тому навіть з виточеним токеном, нападник не міг нічого змінити — просто прочитати дані замовлення.”

** PKCE (Proof Key for Code Exchange) ** — розширення потоку кодів авторизації, яке запобігає обміну перехопленим кодом авторизації з атакуючим, потрібне для публічних клієнтів, таких як мобільні та односторінкові програми, які не можуть безпечно зберігати секрет клієнта. “Оскільки це є односторінкова програма без можливості зберегти секрет конфіденційним, ми повинні використовувати PKCE — він прив’язує обмін кодом до того ж клієнта, який почав поток.”

Звичайні фрази

• Який тип гранту ми використовуємо тут — авторизаційний код, або клієнтські дані?»
• Чи є обсяг токена доступу достатньо вузьким, або він запитує більше, ніж йому потрібно?»
• Чи ми використовуємо PKCE на цьому потоці, оскільки це публічний клієнт?
• Як довго живуть оновлювані токени, перш ніж їм потрібна повторна автентифікація?
• «Чи це аутентифікація чи авторизація, яку ми насправді тут робимо?»

Приклади висловлювань

Перегляд налаштувань OAuth нової інтеграції: “Цей клієнт запитує обсяг admin:all для можливості, яка потребує лише читання профілів користувачів — чи можемо ми зменшити обсяг запиту перед його надсиланням?”

Пояснення помилки закінчення сеансу: “Користувачів виключали з системи кожні п’ятнадцять хвилин, тому що ми не використовували токен оновлення для тихого відновлення токена доступу - ми просто дозволяли сеансу загинути і змушували до повного повторного входу в систему.”

Позначити прогалини безпеки під час перегляду коду:

• “Це односторінкова програма, яка виконує поток кодів авторизації без PKCE, що означає, що перехоплений код може бути обміняний будь- ким. Нам потрібно додати PKCE, перш ніж це піде в виробництво.”*

Професійні поради

• Розрізняти ** автентифікацію ** (“хто ви”) від ** авторизації ** (“що ви можете робити”) явно - OAuth2 є фундаментально авторизаційною структурою, і об’єднання двох призводить до реальних прогалин безпеки.
• Завжди називайте конкретний ** тип надання ** в обговореннях проекту, а не кажучи “ми використовуємо OAuth” - код авторизації, клієнтські дані і потоки пристроїв вирішують різні проблеми і мають різні властивості безпеки.
• Відкидати запити з надто широким ** обсягом ** під час перегляду коду — конкретний запит повинен відповідати конкретному праву, якого потребує функція.
• Вимагати ** PKCE ** для будь- якого публічного клієнта (мобільного, SPA) за допомогою потоку коду авторизації — позначте його відсутність як проблему безпеки, а не як параметр стилю.

Практичні вправи

1. Напишіть речення, яке відрізняє токен доступу від токену оновлення.
2. Пояснити, чому PKCE важливий для односторінкової програми.
3. Описує, як виглядає запит OAuth з вузьким обсягом у порівнянні з широким.

На практиці: Навігація Nuance в співпраці

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

Уявіть, що ви переглядаєте запит на завантаження, надісланий колегою. Вони реалізували нову кінцеву точку API, яка вимагає згоди користувача на доступ до певних даних. Замість того, щоб просто сказати «Це потребує більшої безпеки», що може здатися нечітким і відвертим, більш конструктивним підходом було б: «Чи можемо ми покращити поток тут, щоб явно запитати про обсяг «профіль» під час авторизації? Поки що, здається, програма непрямо запитує ширший доступ, ніж це необхідно. Ми повинні переконатися, що користувач точно розуміє, до яких даних надається доступ, ідеально, якщо на екрані згоди буде представлено чітке і коротке пояснення запитаних обсягів. Це відповідає найкращим практикам для мінімізації потенційних вразливостей. “Зауважте, як конкретна мова - “явно запит”, “обсяг профілю”, “екран згоди” - направляє увагу колеги на дії, а не критикує невизначений проблему.

Аналогічно, у дискусіях Slack щодо дизайну API, уникайте фраз на зразок « просто використовуйте OAuth2 ». Це надто широке значення і не передає розуміння складності, що лежить в основі. Замість цього запропонуйте щось на зразок: « Давайте використаємо делегований потік надання з типом надання « код авторизації » для цієї конкретної інтеграції. Це дозволяє нам безпечно отримати токени доступу від імені користувача, мінімізуючи пряме виставлення наших реєстраційних даних. Ми також повинні визначити гранулярні обсяги, такі як’read_profile’ і ‘write_posts’, щоб переконатися, що ми запитуємо тільки ті дані, які абсолютно необхідні для функціональності. “Оформлення його з точки зору наслідків безпеки (“зменшення прямого виставлення наших реєстраційних даних програми”) відповідає пріоритетам розробника.

Нарешті, при написанні описів PR, будьте докладними про те, * чому * ви реалізуєте певний поток OAuth2. Не просто вкажіть « Реалізовано OAuth2 ». Замість цього: « Реалізовано поток надання авторизаційного коду для полегшення безпечного доступу до даних користувача через API Google. Цей підхід дозволяє нашій програмі запитувати токен доступу від Google, який потім використовується для автентифікації запитів до API Google Диска. Область « диск » була явно запитана, надаючи лише необхідні права доступу для операцій з файлами. » Цей рівень деталізації демонструє ретельне розуміння і допомагає рецензентам оцінити правильність реалізації.

Ось приклад того, як ви можете скористатися curl для отримання токена доступу за допомогою потоку надання коду авторизації:

curl -X POST \
  https://oauth2.googleapis.com/token \
  -d client_id=YOUR_CLIENT_ID \
  -d client_secret=YOUR_CLIENT_SECRET \
  -d grant_type=authorization_code \
  -d scope=drive \
  -d code=AUTHORIZATION_CODE

(Замініть YOUR_CLIENT_ID, YOUR_CLIENT_SECRET і AUTHORIZATION_CODE вашими справжніми даними). Ця команда демонструє конкретне застосування обговорюваного словника — явний запит на обсяг « диска », використання типу надання коду авторизації і детальний опис необхідних параметрів.