- Код авторизації + секрет клієнта: для вебзастосунків із серверною частиною
- Код авторизації + PKCE: для нативних застосунків, інструментів CLI, SPA та інших публічних клієнтів, які не можуть безпечно зберігати секрет клієнта
- Надання авторизації пристрою: для клієнтів, які взагалі не можуть прийняти переспрямування браузера, наприклад CLI, що працює через SSH, у контейнері або хмарному середовищі розробки
Створення застосунку OAuth
- У своєму обліковому записі Teable перейдіть до розділу Settings > OAuth Apps.
- Натисніть New OAuth Apps, щоб створити новий застосунок.
-
Заповніть обов’язкові відомості:
- Назва застосунку OAuth: описова назва вашого застосунку
- URL-адреса головної сторінки: повна URL-адреса вебсайту вашого застосунку
- URL-адреса зворотного виклику: URL-адреса, на яку користувачів буде переспрямовано після авторизації
- Області дозволів: дозволи, потрібні вашому застосунку
- Увімкнути потік пристрою: за замовчуванням вимкнено. Увімкніть, лише якщо ваш застосунок виконує вхід користувачів за кодом пристрою
- Після створення застосунку згенеруйте секрет клієнта. Обов’язково скопіюйте та збережіть його в безпечному місці: надалі переглянути його буде неможливо.
Ви отримаєте Client ID, після чого потрібно згенерувати Client Secret. Зберігайте ці облікові дані в безпеці й ніколи не розкривайте їх у клієнтському коді. Для потоку PKCE секрет клієнта не потрібен.
Доступні області дозволів
Області дозволів визначають, які дії може виконувати ваш застосунок OAuth. Доступні області дозволів згруповано за типом ресурсу:Потік коду авторизації OAuth 2.0
Teable реалізує стандартний потік коду авторизації OAuth 2.0:Крок 1. Переспрямуйте користувачів на сторінку авторизації
Спрямуйте користувачів до кінцевої точки авторизації з параметрами вашого застосунку:
Приклад:
Крок 2. Авторизація користувача
Користувачі побачать сторінку авторизації з такими відомостями:- Назва й логотип вашого застосунку
- Запитані дозволи (області дозволів)
- Варіанти надання або відхилення доступу
Крок 3. Обробіть зворотний виклик
Коли користувач надає (або відхиляє) доступ, Teable переспрямовує його на вашу URL-адресу зворотного виклику: У разі успіху:Крок 4. Обміняйте код на токени
Обміняйте код авторизації на токени доступу й оновлення:
Приклад запиту:
Потік авторизації PKCE
PKCE (Proof Key for Code Exchange) призначено для застосунків, які не можуть безпечно зберігати секрет клієнта, наприклад нативних настільних і мобільних застосунків, інструментів CLI або односторінкових застосунків.Крок 1. Згенеруйте параметри PKCE
Перед початком авторизації клієнт має згенерувати пару параметрів PKCE:Крок 2. Переспрямуйте користувачів на сторінку авторизації
Приклад:
Крок 3. Обробіть зворотний виклик
Так само, як у стандартному потоці коду авторизації: після схвалення користувачем код авторизації повертається через переспрямування.Крок 4. Обміняйте код і code_verifier на токени
Режим PKCE не потребує
client_secret. Натомість для перевірки ідентичності клієнта використовується code_verifier.Потік авторизації пристрою
Надання авторизації пристрою (RFC 8628) призначене для клієнтів, які не можуть прийняти переспрямування браузера: CLI, що працює через SSH, у контейнері або хмарному середовищі розробки. Ваш клієнт показує URL-адресу й короткий код, користувач надає дозвіл у будь-якому браузері, а вводити щось назад у терміналі не потрібно. Teable дотримується RFC 8628, тому більшість клієнтських бібліотек OAuth можуть виконувати цей потік без спеціального коду. Нижче описано особливості Teable.Запит коду пристрою
ВиконайтеPOST /api/oauth/device/code зі своїм client_id і необов’язковим параметром scope. Ця кінцева точка анонімна, а частоту запитів обмежено до 30 за 15 хвилин з однієї IP-адреси.
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
Відкличте доступ застосунку для всіх користувачів (це може зробити лише автор застосунку):Для користувачів
Відкличте власну авторизацію для певного застосунку:Для застосунків
Застосунки можуть відкликати власний доступ за допомогою токена доступу:Ця кінцева точка приймає лише автентифікацію за токеном доступу, а не автентифікацію сеансу.
Термін дії токенів
Обробка помилок
Поширені відповіді з помилками:Рекомендації
- Виберіть правильний режим: використовуйте режим секрету клієнта для вебзастосунків із серверною частиною, режим PKCE — для нативних застосунків, CLI та SPA, а потік пристрою — коли клієнт не може прийняти переспрямування браузера
- Безпечно зберігайте секрети: ніколи не розкривайте Client Secret у клієнтському коді
- Використовуйте параметр state: завжди додавайте випадковий параметр
state, щоб запобігти атакам CSRF - Запитуйте мінімальні області дозволів: запитуйте лише ті дозволи, які справді потрібні вашому застосунку
- Обробляйте оновлення токенів: реалізуйте автоматичне оновлення токенів до завершення терміну їх дії
- Захистіть сховище токенів: безпечно зберігайте токени доступу й оновлення на своєму сервері

