Що таке доступ до API: API-ключі та OAuth-токени
Доступ до API — це доказ того, хто звертається і що йому дозволено. Як працюють API-ключі та OAuth-токени, коли що обирати і як уберегти їх від витоку.
Коли застосунок звертається до іншого сервісу через API, сервіс має знати, хто звертається і що йому дозволено. Саме це на практиці означає «доступ до API»: облікові дані, що ідентифікують клієнта, і набір прав, прив’язаних до них. Найчастіше трапляються два види — API-ключі та OAuth-токени. Вони схожі: обидва — довгі випадкові рядки, що надсилаються з кожним запитом. Але розв’язують вони різні задачі. У цій статті — як працює кожен, коли що обирати і як їх захищати.
Що означає доступ до API
API — це набір правил, за якими одна програма просить іншу про дані чи дії. Публічні API, як-от прогноз погоди, можуть відповідати будь-кому. Більшість корисних — ні: вони беруть плату за запити, обмежують використання або віддають приватні дані. Тому кожен запит містить доказ того, хто питає, а сервіс перевіряє дві речі:
- Автентифікацію — хто цей клієнт?
- Авторизацію — що цьому клієнту дозволено?
«Отримати доступ до API» зазвичай означає створити акаунт у провайдера, зареєструвати застосунок чи проєкт і отримати облікові дані, що його представляють.
Як працюють API-ключі
API-ключ — довгий випадковий рядок, створений у панелі провайдера, наприклад sk_live_4f9a.... Програма надсилає його з кожним запитом, зазвичай у заголовку:
GET /v1/forecast?city=Kyiv
Authorization: Bearer sk_live_4f9a...Сервер знаходить ключ, визначає проєкт, застосовує його права й ліміти та враховує використання для рахунку. Головна перевага ключів — простота: один рядок, жодних додаткових кроків, зручно зі скриптів і серверів.
Слабкість у тому, що ключ — це «пред’явницький» доступ: хто ним володіє, той і користується, звідки завгодно, доки ключ не відкличуть. Він не спливає сам, зазвичай дає всі права проєкту й ідентифікує проєкт, а не людину.
Як працюють OAuth-токени
OAuth розв’язує іншу задачу: дозволити застосунку діяти від імені користувача, не бачачи його пароля. Коли ви натискаєте «Увійти через Google» чи дозволяєте календарному застосунку читати ваш акаунт Microsoft, працює OAuth:
- Застосунок перенаправляє вас на сторінку входу провайдера.
- Ви входите безпосередньо в провайдера й бачите екран згоди зі списком запитаних прав — scopes, наприклад «читати календар».
- Якщо ви погоджуєтесь, провайдер видає застосунку короткочасний access token, обмежений цими правами, часто разом із refresh token для отримання нових токенів.
- Застосунок надсилає access token з API-запитами так само, як ключ.
Access token зазвичай діє до години. Доступ застосунку можна будь-коли відкликати в налаштуваннях акаунта без зміни пароля. Застосунок не знає вашого пароля й може робити лише те, що дозволяють scopes.
API-ключ і OAuth: порівняння
| API-ключ | OAuth access token | |
|---|---|---|
| Кого представляє | Проєкт або застосунок | Користувача, що надав дозвіл застосунку |
| Як отримати | Скопіювати з панелі | Користувач входить і погоджується |
| Термін дії | Доки не відкличуть | Хвилини чи години, потім оновлення |
| Права | Зазвичай усе, що може проєкт | Лише погоджені scopes |
| Складність | Мінімальна | Перенаправлення, реєстрація клієнта, зберігання токенів |
| Найкраще для | Сервер-сервер, скрипти, власні дані | Застосунків, що працюють з акаунтами інших людей |
Що обрати
API-ключ — коли ваш сервер звертається до сервісу від вашого ж імені: розсилка пошти через провайдера, курси валют, виклик AI-моделі. Стороннього користувача немає, тож простота перемагає.
OAuth — коли застосунку потрібні дані, що належать його користувачам: файли, контакти, соцмережі, календарі. Просити в людей паролі небезпечно, і більшість провайдерів це забороняє.
Багато сервісів пропонують обидва варіанти, а також проміжні: персональні токени з обраними правами й терміном дії або сервісні акаунти з підписаними токенами замість статичного ключа. Ними варто користуватися — вони обмежують шкоду від витоку.
Як захистити облікові дані API
- Не кладіть ключі в публічний код. Боти знаходять ключі в публічних репозиторіях за лічені хвилини. Зберігайте їх у змінних середовища чи менеджері секретів, а файли конфігурації додайте в
.gitignore. - Не вбудовуйте секретні ключі в сайт чи мобільний застосунок. Усе, що потрапляє до користувача, можна витягти. Звертайтеся до API зі свого сервера або використовуйте ключі, які провайдер прямо позначає як публічні.
- Мінімальні права. Окремі ключі для кожного середовища й сервісу, лише читання чи обмежені scopes, де це можливо.
- Обмежте, де ключ працює. Багато панелей дозволяють прив’язати ключ до IP-адрес, доменів чи застосунків.
- Ротація й відкликання. Періодично замінюйте ключі, а одразу — якщо ключ потрапив у лог, чат чи скриншот. Найчастіше забувають саме відкликати старий.
- Стежте за використанням. Сповіщення про витрати часто першими показують, що ключ витік.
Часті запитання
API-ключ — це те саме, що пароль?
Для програм він виконує схожу роль, але генерується випадково, відкликається без впливу на ваш вхід і може мати обмежені права. Зберігайте його так само таємно, як пароль.
Навіщо OAuth потрібен refresh token?
Access token діє недовго, щоб викрадений токен швидко перестав працювати. Refresh token, що надійно зберігається на сервері, дозволяє отримати новий access token без повторного входу користувача.
Як побачити, які застосунки мають OAuth-доступ до мого акаунта?
У Google, Microsoft, GitHub і більшості великих провайдерів є сторінка «Підключені застосунки» чи «Доступ сторонніх застосунків», де можна переглянути й відкликати доступ.
Що робити, якщо ключ витік?
Спершу відкличте його в панелі провайдера, потім створіть новий і оновіть конфігурацію. Видалити коміт недостатньо — копії вже можуть існувати.
Коротко: доступ до API — це доказ того, хто ви і що вам дозволено. API-ключі ідентифікують проєкт і ідеальні для власних викликів сервер-сервер. OAuth-токени дозволяють застосунку діяти від імені користувача з обмеженими правами, які можна відкликати. Хоч що ви використовуєте — тримайте це поза публічним кодом, давайте мінімальні права й відкликайте за першої ознаки витоку.