- 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
- Ve a Configuración > Aplicaciones OAuth en tu cuenta de Teable.
- Haz clic en Nueva aplicación OAuth para crear una aplicación.
-
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
- 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: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:
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
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:Paso 4: Intercambiar el código por tokens
Intercambia el código de autorización por tokens de acceso y actualización:
Solicitud de ejemplo:
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
Ejemplo:
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
El modo PKCE no requiere
client_secret. En su lugar, se usa code_verifier para verificar la identidad del cliente.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.Solicitar un código de dispositivo
Envía una solicitudPOST /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.
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 solicitudPOST /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 encabezadoAuthorization de las solicitudes a la API:
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:
Solicitud de ejemplo:
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):Para usuarios
Revoca tu propia autorización para una aplicación específica: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
- 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
- Almacena los secretos de forma segura: Nunca expongas tu secreto de cliente en código del lado del cliente
- Usa el parámetro state: Incluye siempre un parámetro
statealeatorio para evitar ataques CSRF - Solicita el mínimo de ámbitos: Solicita únicamente los permisos que tu aplicación realmente necesita
- Gestiona la actualización de tokens: Implementa la actualización automática del token antes de que caduque
- Almacena los tokens de forma segura: Guarda de forma segura los tokens de acceso y actualización en tu servidor

