Skip to main content
Застосунки OAuth дають стороннім застосункам доступ до Teable від імені користувачів. У цьому посібнику пояснюється, як створити й налаштувати застосунок OAuth, реалізувати потік авторизації OAuth 2.0 і використовувати токени доступу для взаємодії з API Teable. Teable підтримує три режими авторизації OAuth 2.0:
  • Код авторизації + секрет клієнта: для вебзастосунків із серверною частиною
  • Код авторизації + PKCE: для нативних застосунків, інструментів CLI, SPA та інших публічних клієнтів, які не можуть безпечно зберігати секрет клієнта
  • Надання авторизації пристрою: для клієнтів, які взагалі не можуть прийняти переспрямування браузера, наприклад CLI, що працює через SSH, у контейнері або хмарному середовищі розробки

Створення застосунку OAuth

  1. У своєму обліковому записі Teable перейдіть до розділу Settings > OAuth Apps.
  2. Натисніть New OAuth Apps, щоб створити новий застосунок.
  3. Заповніть обов’язкові відомості:
    • Назва застосунку OAuth: описова назва вашого застосунку
    • URL-адреса головної сторінки: повна URL-адреса вебсайту вашого застосунку
    • URL-адреса зворотного виклику: URL-адреса, на яку користувачів буде переспрямовано після авторизації
    • Області дозволів: дозволи, потрібні вашому застосунку
    • Увімкнути потік пристрою: за замовчуванням вимкнено. Увімкніть, лише якщо ваш застосунок виконує вхід користувачів за кодом пристрою
  4. Після створення застосунку згенеруйте секрет клієнта. Обов’язково скопіюйте та збережіть його в безпечному місці: надалі переглянути його буде неможливо.
Ви отримаєте Client ID, після чого потрібно згенерувати Client Secret. Зберігайте ці облікові дані в безпеці й ніколи не розкривайте їх у клієнтському коді. Для потоку PKCE секрет клієнта не потрібен.

Доступні області дозволів

Області дозволів визначають, які дії може виконувати ваш застосунок OAuth. Доступні області дозволів згруповано за типом ресурсу:
Запитуйте лише ті області дозволів, які справді потрібні вашому застосунку. Під час авторизації користувачі бачитимуть запитані дозволи.

Потік коду авторизації OAuth 2.0

Teable реалізує стандартний потік коду авторизації OAuth 2.0:

Крок 1. Переспрямуйте користувачів на сторінку авторизації

Спрямуйте користувачів до кінцевої точки авторизації з параметрами вашого застосунку:
Параметри запиту: Приклад:

Крок 2. Авторизація користувача

Користувачі побачать сторінку авторизації з такими відомостями:
  • Назва й логотип вашого застосунку
  • Запитані дозволи (області дозволів)
  • Варіанти надання або відхилення доступу
Якщо користувач уже авторизував ваш застосунок (за замовчуванням протягом останніх 7 днів), його буде негайно переспрямовано без повторного показу сторінки авторизації.

Крок 3. Обробіть зворотний виклик

Коли користувач надає (або відхиляє) доступ, Teable переспрямовує його на вашу URL-адресу зворотного виклику: У разі успіху:
У разі відхилення:

Крок 4. Обміняйте код на токени

Обміняйте код авторизації на токени доступу й оновлення:
Тіло запиту: Приклад запиту:
Відповідь:

Потік авторизації PKCE

PKCE (Proof Key for Code Exchange) призначено для застосунків, які не можуть безпечно зберігати секрет клієнта, наприклад нативних настільних і мобільних застосунків, інструментів CLI або односторінкових застосунків.

Крок 1. Згенеруйте параметри PKCE

Перед початком авторизації клієнт має згенерувати пару параметрів PKCE:

Крок 2. Переспрямуйте користувачів на сторінку авторизації

Параметри запиту: Приклад:
У режимі PKCE параметр redirect_uri підтримує loopback-адреси (http://127.0.0.1, http://[::1], http://localhost) із гнучким зіставленням портів — не потрібно точно реєструвати кожен порт.

Крок 3. Обробіть зворотний виклик

Так само, як у стандартному потоці коду авторизації: після схвалення користувачем код авторизації повертається через переспрямування.

Крок 4. Обміняйте код і code_verifier на токени

Тіло запиту:
Режим PKCE не потребує client_secret. Натомість для перевірки ідентичності клієнта використовується code_verifier.
Приклад запиту:
Формат відповіді такий самий, як у стандартному потоці коду авторизації.

Потік авторизації пристрою

Надання авторизації пристрою (RFC 8628) призначене для клієнтів, які не можуть прийняти переспрямування браузера: CLI, що працює через SSH, у контейнері або хмарному середовищі розробки. Ваш клієнт показує URL-адресу й короткий код, користувач надає дозвіл у будь-якому браузері, а вводити щось назад у терміналі не потрібно. Teable дотримується RFC 8628, тому більшість клієнтських бібліотек OAuth можуть виконувати цей потік без спеціального коду. Нижче описано особливості Teable.
Потік пристрою за замовчуванням вимкнено. Перш ніж використовувати його, увімкніть Увімкнути потік пристрою в налаштуваннях застосунку OAuth. Будь-хто, хто знає ваш Client ID, може запустити цей потік від імені вашого застосунку, тому вмикайте його, лише якщо він потрібен застосунку. Повторне вимкнення також зупиняє запити, які вже очікують на схвалення.

Запит коду пристрою

Виконайте POST /api/oauth/device/code зі своїм client_id і необов’язковим параметром scope. Ця кінцева точка анонімна, а частоту запитів обмежено до 30 за 15 хвилин з однієї IP-адреси.
Обидва коди діють 15 хвилин (BACKEND_OAUTH_DEVICE_CODE_EXPIRE_IN), а interval визначає мінімальну кількість секунд між опитуваннями. Виведіть verification_uri та user_code. На цій сторінці користувач входить у систему, вводить код і перевіряє назву вашого застосунку, головну сторінку та запитані області дозволів, перш ніж надати або відхилити доступ. Сторінка застерігає не схвалювати код, запит на який користувач не ініціював самостійно. Кожен код можна використати лише один раз.
Teable не повертає verification_uri_complete, і ваш клієнт не повинен створювати його самостійно. Схвалений код виконує вхід користувача, який його схвалив, до його власного облікового запису Teable, тому посилання, що вже містить код, є саме тим механізмом, на який спирається фішинг із кодом пристрою.

Опитування для отримання токенів

Виконайте POST /api/oauth/access_token із grant_type=urn:ietf:params:oauth:grant-type:device_code, значенням device_code і своїм client_id. Публічні клієнти не надсилають client_secret; конфіденційні клієнти додають його так само, як в інших потоках. Доки код не схвалено, кінцева точка повертає помилку замість токенів: Після схвалення користувачем відповідь міститиме таке саме корисне навантаження токена, як і в інших потоках.

Використання токенів доступу

Додавайте токен доступу до заголовка Authorization у запитах API:
Зазвичай перший крок після отримання токена — отримати всі Бази, доступні поточному користувачу:
Ця кінцева точка повертає всі Бази, до яких поточний користувач має дозвіл на доступ. Значення baseId із відповіді можна використовувати в наступних викликах API.

Оновлення токенів доступу

Коли термін дії токена доступу закінчиться, скористайтеся токеном оновлення, щоб отримати новий:
Тіло запиту: Приклад запиту:
Після оновлення попередній токен оновлення стає недійсним (ротація токенів оновлення). Завжди зберігайте новий токен оновлення з відповіді.

Відкликання доступу

Для власників застосунків OAuth

Відкличте доступ застосунку для всіх користувачів (це може зробити лише автор застосунку):
Це видаляє записи авторизації та токени всіх користувачів і повністю унеможливлює доступ застосунку до даних будь-якого користувача.

Для користувачів

Відкличте власну авторизацію для певного застосунку:
Це робить недійсними лише токени доступу й оновлення поточного користувача, не впливаючи на інших користувачів. Користувачі також можуть відкликати доступ на сторінці налаштувань Авторизовані застосунки.

Для застосунків

Застосунки можуть відкликати власний доступ за допомогою токена доступу:
Ця кінцева точка приймає лише автентифікацію за токеном доступу, а не автентифікацію сеансу.

Термін дії токенів

Обробка помилок

Поширені відповіді з помилками:

Рекомендації

  1. Виберіть правильний режим: використовуйте режим секрету клієнта для вебзастосунків із серверною частиною, режим PKCE — для нативних застосунків, CLI та SPA, а потік пристрою — коли клієнт не може прийняти переспрямування браузера
  2. Безпечно зберігайте секрети: ніколи не розкривайте Client Secret у клієнтському коді
  3. Використовуйте параметр state: завжди додавайте випадковий параметр state, щоб запобігти атакам CSRF
  4. Запитуйте мінімальні області дозволів: запитуйте лише ті дозволи, які справді потрібні вашому застосунку
  5. Обробляйте оновлення токенів: реалізуйте автоматичне оновлення токенів до завершення терміну їх дії
  6. Захистіть сховище токенів: безпечно зберігайте токени доступу й оновлення на своєму сервері

Повні приклади

Node.js (код авторизації + секрет клієнта)

Python (режим PKCE для інструментів CLI)

Останнє оновлення 4 вересня 2026 р.