Skip to main content
Les applications OAuth permettent à des applications tierces d’accéder à Teable au nom des utilisateurs. Ce guide explique comment créer et configurer une application OAuth, implémenter le flux d’autorisation OAuth 2.0 et utiliser des jetons d’accès pour interagir avec l’API Teable. Teable prend en charge trois modes d’autorisation OAuth 2.0 :
  • Code d’autorisation + secret client : pour les applications web avec un serveur backend
  • Code d’autorisation + PKCE : pour les applications natives, les outils CLI, les SPA et les autres clients publics qui ne peuvent pas stocker de façon sécurisée un secret client
  • Flux d’autorisation d’appareil : pour les clients qui ne peuvent pas recevoir de redirection depuis un navigateur, tels qu’un CLI exécuté via SSH, dans un conteneur ou dans un IDE cloud

Créer une application OAuth

  1. Accédez à Paramètres > Applications OAuth dans votre compte Teable.
  2. Cliquez sur Nouvelles applications OAuth pour créer une nouvelle application.
  3. Renseignez les informations requises :
    • Nom de l’application OAuth : un nom descriptif pour votre application
    • URL de la page d’accueil : l’URL complète du site web de votre application
    • URL de rappel : l’URL vers laquelle les utilisateurs seront redirigés après l’autorisation
    • Scopes : les autorisations requises par votre application
    • Activer le flux d’appareil : désactivé par défaut. Activez-le uniquement si votre application connecte les utilisateurs avec un code d’appareil
  4. Après avoir créé l’application, générez un secret client. Veillez à le copier et à le stocker de manière sécurisée : vous ne pourrez plus le consulter.
Vous recevrez un ID client et devrez générer un secret client. Protégez ces identifiants et ne les exposez jamais dans du code côté client. Si vous utilisez le flux PKCE, aucun secret client n’est requis.

Scopes disponibles

Les scopes définissent les actions que votre application OAuth peut effectuer. Les scopes disponibles sont organisés par type de ressource :
Demandez uniquement les scopes dont votre application a réellement besoin. Les utilisateurs verront les autorisations demandées pendant l’autorisation.

Flux OAuth 2.0 avec code d’autorisation

Teable implémente le flux standard OAuth 2.0 avec code d’autorisation :

Étape 1 : rediriger les utilisateurs vers l’autorisation

Dirigez les utilisateurs vers le point de terminaison d’autorisation avec les paramètres de votre application :
Paramètres de requête : Exemple :

Étape 2 : autorisation de l’utilisateur

Les utilisateurs verront une page d’autorisation affichant :
  • Le nom et le logo de votre application
  • Les autorisations demandées (scopes)
  • Des options pour approuver ou refuser l’accès
Si l’utilisateur a déjà autorisé votre application (dans les 7 derniers jours par défaut), il sera redirigé immédiatement sans revoir la page d’autorisation.

Étape 3 : gérer le rappel

Après que l’utilisateur a approuvé (ou refusé), Teable redirige vers votre URL de rappel : En cas de réussite :
En cas de refus :

Étape 4 : échanger le code contre des jetons

Échangez le code d’autorisation contre des jetons d’accès et d’actualisation :
Corps de la requête : Exemple de requête :
Réponse :

Flux d’autorisation PKCE

PKCE (Proof Key for Code Exchange) est conçu pour les applications qui ne peuvent pas stocker de façon sécurisée un secret client, telles que les applications de bureau natives, les applications mobiles, les outils CLI ou les applications monopages.

Étape 1 : générer les paramètres PKCE

Avant d’initialiser l’autorisation, le client doit générer une paire de paramètres PKCE :

Étape 2 : rediriger les utilisateurs vers l’autorisation

Paramètres de requête : Exemple :
En mode PKCE, redirect_uri prend en charge les adresses loopback (http://127.0.0.1, http://[::1], http://localhost) avec une correspondance de port flexible : vous n’avez pas besoin d’enregistrer exactement chaque port.

Étape 3 : gérer le rappel

Identique au flux standard avec code d’autorisation : après l’approbation de l’utilisateur, le code d’autorisation est renvoyé via redirection.

Étape 4 : échanger le code + code_verifier contre des jetons

Corps de la requête :
Le mode PKCE ne requiert pas de client_secret. Le code_verifier est utilisé à la place pour vérifier l’identité du client.
Exemple de requête :
Le format de réponse est le même que pour le flux standard avec code d’autorisation.

Flux d’autorisation d’appareil

L’autorisation d’appareil (RFC 8628) est destinée aux clients qui ne peuvent pas recevoir de redirection depuis un navigateur : un CLI exécuté via SSH, dans un conteneur ou dans un IDE cloud. Votre client affiche une URL et un code court, l’utilisateur approuve dans n’importe quel navigateur, et rien n’est à saisir à nouveau dans le terminal. Teable suit la RFC 8628 ; la plupart des bibliothèques clientes OAuth peuvent donc piloter ce flux sans code personnalisé. La suite décrit les éléments spécifiques à Teable.
Le flux d’appareil est désactivé par défaut. Activez Activer le flux d’appareil dans les paramètres de votre application OAuth avant de l’utiliser. Toute personne connaissant votre ID client peut démarrer ce flux au nom de votre application ; ne l’activez donc que si votre application en a besoin. Le désactiver à nouveau arrête également les demandes déjà en attente d’approbation.

Demander un code d’appareil

POST /api/oauth/device/code avec votre client_id et un scope facultatif. Le point de terminaison est anonyme et limité à 30 requêtes par 15 minutes et par adresse IP.
Les deux codes expirent après 15 minutes (BACKEND_OAUTH_DEVICE_CODE_EXPIRE_IN) et interval correspond au nombre minimal de secondes à attendre entre deux interrogations. Affichez verification_uri et user_code. Sur cette page, l’utilisateur se connecte, saisit le code et consulte le nom, la page d’accueil et les scopes demandés de votre application avant d’approuver ou de refuser. La page l’avertit de ne pas approuver un code qu’il n’a pas initié lui-même. Chaque code ne peut être utilisé qu’une seule fois.
Teable ne renvoie pas verification_uri_complete, et votre client ne doit pas en construire un. Un code approuvé connecte la personne qui l’approuve à son propre compte Teable ; un lien qui contient déjà le code est donc précisément le mécanisme sur lequel repose le hameçonnage par code d’appareil.

Interroger les jetons

POST /api/oauth/access_token avec grant_type=urn:ietf:params:oauth:grant-type:device_code, le device_code et votre client_id. Les clients publics n’envoient pas de client_secret ; les clients confidentiels l’ajoutent comme dans les autres flux. Tant que personne n’a approuvé le code, le point de terminaison répond avec une erreur plutôt qu’avec des jetons : Une fois que l’utilisateur a approuvé, la réponse contient la même charge utile de jeton que les autres flux.

Utiliser des jetons d’accès

Incluez le jeton d’accès dans l’en-tête Authorization des requêtes API :
En général, la première étape après l’obtention d’un jeton consiste à récupérer toutes les Bases accessibles à l’utilisateur actuel :
Ce point de terminaison renvoie toutes les Bases auxquelles l’utilisateur actuel est autorisé à accéder. Vous pouvez utiliser le baseId de la réponse pour les appels API suivants.

Actualiser les jetons d’accès

Lorsqu’un jeton d’accès expire, utilisez le jeton d’actualisation pour en obtenir un nouveau :
Corps de la requête : Exemple de requête :
Après l’actualisation, le précédent jeton d’actualisation devient invalide (rotation des jetons d’actualisation). Stockez toujours le nouveau jeton d’actualisation de la réponse.

Révoquer l’accès

Pour les propriétaires d’applications OAuth

Révoquez l’accès de l’application pour tous les utilisateurs (seul le créateur de l’application peut le faire) :
Cela supprime les enregistrements d’autorisation et les jetons de tous les utilisateurs, empêchant complètement l’application d’accéder aux données de tout utilisateur.

Pour les utilisateurs

Révoquez votre propre autorisation pour une application spécifique :
Cela invalide uniquement les jetons d’accès et jetons d’actualisation de l’utilisateur actuel, sans affecter les autres utilisateurs. Les utilisateurs peuvent également révoquer l’accès depuis leur page de paramètres Applications autorisées.

Pour les applications

Les applications peuvent révoquer leur propre accès à l’aide d’un jeton d’accès :
Ce point de terminaison accepte uniquement l’authentification par jeton d’accès, et non l’authentification par session.

Expiration des jetons

Gestion des erreurs

Réponses d’erreur courantes :

Bonnes pratiques

  1. Choisissez le bon mode : utilisez le mode avec secret client pour les applications web avec backend, le mode PKCE pour les applications natives/CLI/SPA et le flux d’appareil lorsque le client ne peut pas recevoir de redirection depuis un navigateur
  2. Stockez les secrets de manière sécurisée : n’exposez jamais votre secret client dans du code côté client
  3. Utilisez le paramètre state : incluez toujours un paramètre state aléatoire pour empêcher les attaques CSRF
  4. Demandez le minimum de scopes : demandez uniquement les autorisations dont votre application a réellement besoin
  5. Gérez l’actualisation des jetons : implémentez l’actualisation automatique des jetons avant leur expiration
  6. Sécurisez le stockage des jetons : stockez les jetons d’accès et d’actualisation de manière sécurisée sur votre serveur

Exemples complets

Node.js (code d’autorisation + secret client)

Python (mode PKCE pour les outils CLI)

Dernière modification le 4 septembre 2026