Sessions et tokens

Chaque requête vers l'API de la plateforme est authentifiée en tant qu'utilisateur au sein d'un locataire. Cette page décrit comment le serveur transforme une requête entrante en une identité et une portée locataire/site. Pour obtenir un identifiant, voir Authentification.

Ordre de résolution des identifiants

Le serveur examine les identifiants dans un ordre fixe et retient le premier valide :

1. Authorization: Bearer <JWT> : le serveur vérifie la signature et l'expiration du JWT. C'est le bon choix pour les scripts et les appels de service à service. Un token Bearer invalide ou expiré est ignoré, et le serveur passe à l'identifiant suivant.
2. Cookie de session __Secure-authjs.session-token : l'identifiant que porte déjà un navigateur connecté à la console.

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

Le token Bearer et le cookie de session contiennent le même JWT : le cookie est simplement la manière dont le navigateur le conserve. Sa durée dépend du mode de connexion : 24 heures après une connexion par mot de passe. Voir Authentification.

Portée locataire et site

L'authentification établit qui vous êtes ; une étape distincte établit dans quel locataire et quel site vous agissez.

• L'espace d'origine. Le token porte le tenantId et le siteId de votre compte : c'est votre locataire et votre site d'origine.
• Plusieurs locataires ou sites. Un compte peut avoir accès à plusieurs locataires ou sites (par ses appartenances). Dans la console, le locataire et le site actifs sont ceux choisis dans le sélecteur.
• Contrôle d'accès. Avant l'exécution de toute procédure protégée, la plateforme vérifie que votre compte peut agir dans le locataire et le site demandés : ils doivent être actifs, et votre compte doit y avoir accès (locataire d'origine ou appartenance). Sinon, l'appel échoue avec FORBIDDEN (« The requested tenant/site scope is not authorized. »).

Les en-têtes de requête ne choisissent pas le locataire : sur les hôtes publics, c'est la plateforme qui fixe la portée. Le modèle locataire/site est décrit dans le Modèle de données.

Erreurs d'authentification

Un token expiré ne produit pas d'erreur propre : il est ignoré, et l'appel aboutit à UNAUTHORIZED comme s'il n'y avait pas d'identifiant. Réponse type, ici pour auth.getSession :

{"error":{"json":{"message":"Please log in to access this feature. Your session may have expired.","code":-32001,"data":{"code":"UNAUTHORIZED","httpStatus":401,"path":"auth.getSession","zodError":null}}}}

Obtenir un token

Le plus simple est le bouton Se connecter avec Inklura de l'Explorateur d'API :

1. L'explorateur ouvre la console Inklura. Connectez-vous comme d'habitude : mot de passe, lien d'invitation ou authentification unique. Toute connexion qui ouvre la console convient.
2. La console affiche votre compte, l'espace actif et la date d'expiration du token, puis vous demande d'autoriser l'explorateur.
3. Vous revenez sur l'explorateur connecté. Le token est renseigné, et « Copier le cURL » l'inclut, prêt pour votre terminal.

Le token est votre session console : il porte vos droits jusqu'à son expiration et ne peut pas être révoqué avant. L'explorateur le garde pour l'onglet en cours seulement, sauf si vous cochez « Se souvenir du token sur cet appareil ».

Il n'existe pas de création de clé API en libre-service pour l'API complète. Pour une intégration durable, écrivez à support@inklura.fr pour mettre en place un identifiant de service. Le parcours complet (cookie de session, JWT Bearer, OIDC, invitation) se trouve dans Authentification.

Les feeds de contenu font exception : ils utilisent leur propre FeedApiKey (feed_…) à portée limitée, plutôt qu'une session utilisateur. Voir Modèle de données et Authentification.