Skip to main content
OAuth-приложения позволяют сторонним приложениям получать доступ к Teable от имени пользователей. В этом руководстве объясняется, как создать и настроить OAuth-приложение, реализовать поток авторизации OAuth 2.0 и использовать токены доступа для взаимодействия с API Teable. Teable поддерживает три режима авторизации OAuth 2.0:
  • Код авторизации + секрет клиента: для веб-приложений с серверной частью
  • Код авторизации + PKCE: для нативных приложений, инструментов CLI, SPA и других публичных клиентов, которые не могут безопасно хранить секрет клиента
  • Предоставление авторизации устройства: для клиентов, которые вообще не могут получить перенаправление браузера, например CLI, запущенного через SSH, в контейнере или в облачной IDE

Создание OAuth-приложения

  1. Перейдите в раздел Настройки > OAuth-приложения в своей учетной записи Teable.
  2. Нажмите Новое OAuth-приложение, чтобы создать новое приложение.
  3. Заполните необходимую информацию:
    • Название OAuth-приложения: понятное название вашего приложения
    • URL главной страницы: полный URL веб-сайта вашего приложения
    • URL обратного вызова: URL, на который пользователи будут перенаправлены после авторизации
    • Области действия: разрешения, необходимые вашему приложению
    • Включить поток устройства: по умолчанию выключено. Включайте только если ваше приложение выполняет вход пользователей с помощью кода устройства
  4. После создания приложения сгенерируйте секрет клиента. Обязательно скопируйте и надежно сохраните его — повторно увидеть его будет нельзя.
Вы получите идентификатор клиента и должны будете сгенерировать секрет клиента. Надежно храните эти учетные данные и никогда не раскрывайте их в клиентском коде. При использовании потока 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, внутри контейнера или в облачной IDE. Ваш клиент показывает URL и короткий код, пользователь подтверждает действие в любом браузере, и в терминал ничего вводить не нужно. Teable следует RFC 8628, поэтому большинство библиотек OAuth-клиентов могут реализовать этот поток без специального кода. Ниже описано то, что специфично для Teable.
Поток устройства по умолчанию выключен. Перед использованием включите Включить поток устройства в настройках OAuth-приложения. Любой, кто знает ваш идентификатор клиента, может запустить этот поток от имени вашего приложения, поэтому включайте его только при необходимости. Повторное отключение также остановит запросы, уже ожидающие подтверждения.

Запрос кода устройства

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-запросов:
Как правило, первым шагом после получения токена является получение всех Баз, доступных текущему пользователю:
Эта конечная точка возвращает все Базы, к которым текущий пользователь имеет разрешение на доступ. Для последующих вызовов API можно использовать baseId из ответа.

Обновление токенов доступа

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

Отзыв доступа

Для владельцев OAuth-приложений

Отзовите доступ приложения у всех пользователей (это может сделать только создатель приложения):
Это удаляет записи авторизации и токены всех пользователей, полностью предотвращая доступ приложения к данным любого пользователя.

Для пользователей

Отзовите собственную авторизацию для конкретного приложения:
Это делает недействительными только токены доступа и токены обновления текущего пользователя, не затрагивая других пользователей. Пользователи также могут отозвать доступ на странице настроек Авторизованные приложения.

Для приложений

Приложения могут отозвать собственный доступ с помощью токена доступа:
Эта конечная точка принимает только аутентификацию токеном доступа, но не сеансовую аутентификацию.

Срок действия токенов

Обработка ошибок

Распространенные ответы с ошибками:

Рекомендации

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

Полные примеры

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

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

Последнее изменение 4 сентября 2026 г.