Authentification

Chaque appel à l'API Inklura est authentifié en tant qu'utilisateur au sein d'un locataire. Il n'existe pas de « clé API d'organisation » distincte pour l'API générale : une requête porte une identité de session, et le serveur en déduit la portée locataire/site (voir la portée locataire).

Astuce

Dans l'Explorateur d'API, Se connecter avec Inklura vous donne un token via la console, quelle que soit votre façon de vous y connecter. L'explorateur génère ensuite un cURL prêt à l'emploi pour n'importe quel endpoint. Le token reste dans votre navigateur (pour l'onglet en cours seulement, sauf si vous demandez de le mémoriser). « Copier le cURL » s'exécute depuis votre propre terminal ; le bouton « Envoyer » de la page relaie la requête, token compris, vers l'API en passant par le site de documentation.

Les quatre manières de s'authentifier

Méthode À utiliser pour Comment
Cookie de session La console dans un navigateur __Secure-authjs.session-token, défini à la connexion
JWT Bearer Scripts, serveurs, service à service Authorization: Bearer <jwt>
OIDC Connexion déléguée via le fournisseur d'identité de la plateforme Authorization code + PKCE auprès de auth.1clic.pro
Clé API de feed Les feeds de contenu d'un site Une clé de feed (feed_…), avec sa propre limite horaire

Cookie de session

Se connecter sur manage.inklura.fr crée un cookie de session __Secure-authjs.session-token. Il contient un JWT signé par la plateforme, valable 24 heures après une connexion par mot de passe. Le cookie appartient à l'hôte de la console : les autres applications *.inklura.fr gardent leur propre session, et la connexion partagée auprès du fournisseur d'identité connecte l'utilisateur à chacune d'elles (voir SSO).

JWT Bearer (accès programmatique)

Pour tout ce qui n'est pas un navigateur (un script, un service backend, une application Inklura qui en appelle une autre), envoyez le JWT de session en tant que token Bearer :

curl https://manage.inklura.fr/api/trpc/auth.getSession \
  -H "Authorization: Bearer $INKLURA_TOKEN"

Le serveur vérifie la signature et l'expiration du JWT, puis agit en tant qu'utilisateur du token, dans le locataire et le site de cet utilisateur. Un token invalide ou expiré est traité comme une absence d'identifiant.

Note

Les tokens sont émis uniquement par la plateforme : il n'existe pas de création de clé API en libre-service pour l'API complète. Pour obtenir votre token de session, utilisez Se connecter avec Inklura dans l'Explorateur d'API (voir la section « Obtenir un token » de Sessions et tokens). Pour une intégration durable, écrivez à support@inklura.fr pour mettre en place un identifiant de service.

OIDC (auth.1clic.pro)

Le fournisseur d'identité d'Inklura est un serveur OIDC, à l'adresse auth.1clic.pro (document de découverte : https://auth.1clic.pro/.well-known/openid-configuration). La console utilise un flux authorization code avec PKCE (S256) :

  1. La console redirige l'utilisateur vers auth.1clic.pro/oauth2/authorize.
  2. L'utilisateur s'authentifie.
  3. Au retour, le code est échangé contre des tokens (vérifiés avec le JWKS du fournisseur) et une session Inklura est créée.

Si vous construisez une application first-party qui doit participer à la connexion de la plateforme, un client doit être enregistré auprès du fournisseur d'identité : voir Authentification unique.

Invitations par lien

Les administrateurs invitent les utilisateurs avec un lien signé plutôt qu'avec un mot de passe :

  1. Depuis la console, un administrateur crée une invitation pour un locataire et un site (éventuellement avec un rôle et une adresse e-mail imposée). Le lien porte une date d'expiration.
  2. Le destinataire ouvre le lien reçu et peut choisir un mot de passe (8 caractères minimum). Si le lien impose une adresse e-mail, seule cette adresse peut l'utiliser.
  3. La plateforme vérifie la signature et l'expiration du lien, crée le compte de l'utilisateur (ou ajoute l'accès à un compte existant) et ouvre sa session sur la console. Un compte existant qui a déjà un mot de passe le garde : une invitation ne le remplace jamais.

Clés API de feed

Les feeds de contenu d'un site peuvent être protégés par leurs propres clés à portée limitée plutôt que par une session utilisateur :

  • Clé de feed : une clé avec le préfixe feed_. Chaque clé a une limite de requêtes par heure (rateLimit, de 0 à 10000, 1 000 par défaut, 0 pour illimité), une liste d'IP autorisées facultative (allowedIps : adresses IPv4 ou IPv6 et plages CIDR IPv4, séparées par des virgules), une date d'expiration expiresAt facultative et un ensemble de permissions (full_content, unlimited_requests, custom_cache ; full_content par défaut). Les clés se gèrent via le router tRPC feedApiKeys (list, get, getStats, create, update, regenerate, toggleActive, delete). La clé complète n'est renvoyée qu'une fois, par create ou regenerate : seul son préfixe reste visible ensuite. Un feed qui accepte les clés la lit dans l'en-tête X-Feed-Api-Key, dans Authorization: Bearer feed_… ou dans le paramètre api_key.
  • Clés du widget de chat en direct : le widget de chat en direct intégrable utilise ses propres clés, distinctes des clés de feed.

Ces clés restent l'exception : l'API générale utilise des sessions ou des JWT Bearer.

Portée locataire et site

Votre token nomme le locataire et le site d'origine de votre compte. La portée de chaque appel est résolue à la requête, puis la plateforme la vérifie chaque appel au regard des accès de votre compte, et un locataire ou un site auquel vous n'avez pas accès est refusé avec FORBIDDEN. Voir Sessions et tokens.

Étapes suivantes