Skip to main content
Las aplicaciones OAuth permiten que aplicaciones de terceros accedan a Teable en nombre de los usuarios. Esta guía explica cómo crear y configurar una aplicación OAuth, implementar el flujo de autorización OAuth 2.0 y usar tokens de acceso para interactuar con la API de Teable. Teable admite tres modos de autorización OAuth 2.0:
  • Código de autorización + secreto de cliente: Para aplicaciones web con un servidor backend
  • Código de autorización + PKCE: Para aplicaciones nativas, herramientas de CLI, SPA y otros clientes públicos que no pueden almacenar de forma segura un secreto de cliente
  • Concesión de autorización de dispositivo: Para clientes que no pueden recibir una redirección del navegador, como una CLI ejecutada mediante SSH, en un contenedor o en un IDE en la nube

Crear una aplicación OAuth

  1. Ve a Configuración > Aplicaciones OAuth en tu cuenta de Teable.
  2. Haz clic en Nueva aplicación OAuth para crear una aplicación.
  3. Completa la información requerida:
    • Nombre de la aplicación OAuth: Un nombre descriptivo para tu aplicación
    • URL de la página de inicio: La URL completa del sitio web de tu aplicación
    • URL de devolución de llamada: La URL a la que se redirigirá a los usuarios después de la autorización
    • Ámbitos: Los permisos que necesita tu aplicación
    • Habilitar flujo de dispositivo: Está desactivado de forma predeterminada. Actívalo únicamente si tu aplicación inicia sesión mediante un código de dispositivo
  4. Después de crear la aplicación, genera un secreto de cliente. Asegúrate de copiarlo y almacenarlo de forma segura: no podrás volver a verlo.
Recibirás un ID de cliente y tendrás que generar un secreto de cliente. Mantén seguras estas credenciales y nunca las expongas en código del lado del cliente. Si usas el flujo PKCE, no se requiere un secreto de cliente.

Ámbitos disponibles

Los ámbitos definen qué acciones puede realizar tu aplicación OAuth. Los ámbitos disponibles se organizan por tipo de recurso:
Solicita únicamente los ámbitos que tu aplicación realmente necesita. Los usuarios verán los permisos solicitados durante la autorización.

Flujo de código de autorización OAuth 2.0

Teable implementa el flujo estándar de código de autorización OAuth 2.0:

Paso 1: Redirigir a los usuarios a la autorización

Dirige a los usuarios al endpoint de autorización con los parámetros de tu aplicación:
Parámetros de consulta: Ejemplo:

Paso 2: Autorización del usuario

Los usuarios verán una página de autorización que muestra:
  • El nombre y el logotipo de tu aplicación
  • Los permisos solicitados (ámbitos)
  • Opciones para aprobar o denegar el acceso
Si el usuario ya autorizó tu aplicación anteriormente (de forma predeterminada, en los últimos 7 días), se le redirigirá de inmediato sin volver a mostrarle la página de autorización.

Paso 3: Gestionar la llamada de retorno

Después de que el usuario apruebe (o deniegue), Teable redirige a tu URL de devolución de llamada: En caso de éxito:
En caso de denegación:

Paso 4: Intercambiar el código por tokens

Intercambia el código de autorización por tokens de acceso y actualización:
Cuerpo de la solicitud: Solicitud de ejemplo:
Respuesta:

Flujo de autorización PKCE

PKCE (Proof Key for Code Exchange, o clave de prueba para el intercambio de códigos) está diseñado para aplicaciones que no pueden almacenar de forma segura un secreto de cliente, como aplicaciones nativas de escritorio, aplicaciones móviles, herramientas de CLI o aplicaciones de una sola página.

Paso 1: Generar parámetros PKCE

Antes de iniciar la autorización, el cliente debe generar un par de parámetros PKCE:

Paso 2: Redirigir a los usuarios a la autorización

Parámetros de consulta: Ejemplo:
En el modo PKCE, redirect_uri admite direcciones de bucle invertido (http://127.0.0.1, http://[::1], http://localhost) con coincidencia flexible de puertos, por lo que no es necesario registrar cada puerto de forma exacta.

Paso 3: Gestionar la llamada de retorno

Es igual que el flujo estándar de código de autorización: después de que el usuario dé su aprobación, el código de autorización se devuelve mediante una redirección.

Paso 4: Intercambiar el código + code_verifier por tokens

Cuerpo de la solicitud:
El modo PKCE no requiere client_secret. En su lugar, se usa code_verifier para verificar la identidad del cliente.
Solicitud de ejemplo:
El formato de la respuesta es el mismo que en el flujo estándar de código de autorización.

Flujo de autorización de dispositivo

La concesión de autorización de dispositivo (RFC 8628) está destinada a clientes que no pueden recibir una redirección del navegador: una CLI ejecutada mediante SSH, dentro de un contenedor o en un IDE en la nube. Tu cliente muestra una URL y un código breve, el usuario da su aprobación en cualquier navegador y no es necesario escribir nada de vuelta en la terminal. Teable sigue la RFC 8628, por lo que la mayoría de las bibliotecas de cliente OAuth pueden ejecutar este flujo sin código personalizado. A continuación se detalla lo que es específico de Teable.
El flujo de dispositivo está desactivado de forma predeterminada. Activa Habilitar flujo de dispositivo en la configuración de tu aplicación OAuth antes de usarlo. Cualquier persona que conozca tu ID de cliente puede iniciar este flujo en nombre de tu aplicación, así que actívalo únicamente si tu aplicación lo necesita. Si vuelves a desactivarlo, también se detendrán las solicitudes que ya estén esperando aprobación.

Solicitar un código de dispositivo

Envía una solicitud POST /api/oauth/device/code con tu client_id y un scope opcional. El endpoint es anónimo y está limitado a 30 solicitudes cada 15 minutos por dirección IP.
Ambos códigos caducan después de 15 minutos (BACKEND_OAUTH_DEVICE_CODE_EXPIRE_IN), e interval indica el mínimo de segundos que se debe esperar entre consultas. Muestra verification_uri y user_code. En esa página, el usuario inicia sesión, introduce el código y revisa el nombre, la página de inicio y los ámbitos solicitados de tu aplicación antes de aprobar o denegar la solicitud. La página le advierte que no apruebe ningún código cuyo proceso no haya iniciado personalmente. Cada código se puede usar una sola vez.
Teable no devuelve verification_uri_complete, y tu cliente no debe construirla. Un código aprobado inicia la sesión de quien lo aprueba en su propia cuenta de Teable, por lo que un enlace que ya incluya el código es precisamente el mecanismo en el que se basa el phishing con códigos de dispositivo.

Consultar si hay tokens disponibles

Envía una solicitud POST /api/oauth/access_token con grant_type=urn:ietf:params:oauth:grant-type:device_code, el device_code y tu client_id. Los clientes públicos no envían ningún client_secret; los clientes confidenciales lo añaden como en los demás flujos. Hasta que alguien apruebe el código, el endpoint responde con un error en lugar de tokens: Una vez que el usuario da su aprobación, la respuesta contiene los mismos tokens que en los demás flujos.

Usar tokens de acceso

Incluye el token de acceso en el encabezado Authorization de las solicitudes a la API:
Normalmente, el primer paso después de obtener un token es recuperar todas las Bases accesibles para el usuario actual:
Este endpoint devuelve todas las Bases a las que el usuario actual tiene permiso de acceso. Puedes usar el baseId de la respuesta para las llamadas posteriores a la API.

Actualizar tokens de acceso

Cuando caduque un token de acceso, usa el token de actualización para obtener uno nuevo:
Cuerpo de la solicitud: Solicitud de ejemplo:
Después de la actualización, el token de actualización anterior deja de ser válido (rotación de tokens de actualización). Guarda siempre el nuevo token de actualización incluido en la respuesta.

Revocar el acceso

Para propietarios de aplicaciones OAuth

Revoca el acceso de la aplicación para todos los usuarios (solo puede hacerlo quien creó la aplicación):
Esto elimina los registros de autorización y los tokens de todos los usuarios, e impide por completo que la aplicación acceda a los datos de cualquier usuario.

Para usuarios

Revoca tu propia autorización para una aplicación específica:
Esto solo invalida los tokens de acceso y de actualización del usuario actual, sin afectar a otros usuarios. Los usuarios también pueden revocar el acceso desde la página de configuración de Aplicaciones autorizadas.

Para aplicaciones

Las aplicaciones pueden revocar su propio acceso mediante un token de acceso:
Este endpoint solo acepta autenticación mediante token de acceso, no autenticación de sesión.

Caducidad de los tokens

Gestión de errores

Respuestas de error habituales:

Prácticas recomendadas

  1. Elige el modo adecuado: Usa el modo con secreto de cliente para aplicaciones web con backend, el modo PKCE para aplicaciones nativas, CLI o SPA, y el flujo de dispositivo cuando el cliente no pueda recibir una redirección del navegador
  2. Almacena los secretos de forma segura: Nunca expongas tu secreto de cliente en código del lado del cliente
  3. Usa el parámetro state: Incluye siempre un parámetro state aleatorio para evitar ataques CSRF
  4. Solicita el mínimo de ámbitos: Solicita únicamente los permisos que tu aplicación realmente necesita
  5. Gestiona la actualización de tokens: Implementa la actualización automática del token antes de que caduque
  6. Almacena los tokens de forma segura: Guarda de forma segura los tokens de acceso y actualización en tu servidor

Ejemplos completos

Node.js (código de autorización + secreto de cliente)

Python (modo PKCE para herramientas de CLI)

Última modificación el 4 de septiembre de 2026