- 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
- Accédez à Paramètres > Applications OAuth dans votre compte Teable.
- Cliquez sur Nouvelles applications OAuth pour créer une nouvelle application.
-
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
- 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 :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 :
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
É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 :Étape 4 : échanger le code contre des jetons
Échangez le code d’autorisation contre des jetons d’accès et d’actualisation :
Exemple de requête :
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
Exemple :
É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
Le mode PKCE ne requiert pas de
client_secret. Le code_verifier est utilisé à la place pour vérifier l’identité du client.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.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.
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êteAuthorization des requêtes API :
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 :
Exemple de requête :
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) :Pour les utilisateurs
Révoquez votre propre autorisation pour une application spécifique :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
- 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
- Stockez les secrets de manière sécurisée : n’exposez jamais votre secret client dans du code côté client
- Utilisez le paramètre state : incluez toujours un paramètre
statealéatoire pour empêcher les attaques CSRF - Demandez le minimum de scopes : demandez uniquement les autorisations dont votre application a réellement besoin
- Gérez l’actualisation des jetons : implémentez l’actualisation automatique des jetons avant leur expiration
- Sécurisez le stockage des jetons : stockez les jetons d’accès et d’actualisation de manière sécurisée sur votre serveur

