Sécuriser votre assistant
La sécurité repose sur trois couches qui fonctionnent ensemble : le mode d’authentification, la liste des origines autorisées et, en mode API, la clé d’API. La façon de les combiner dépend de qui doit pouvoir utiliser l’assistant.
Comprendre ce qui est public
Lorsqu’un assistant est intégré sur un site web, l’extrait d’intégration (y compris l’assistantId, l’accessToken (clé d’API) et le serviceURL) se trouve dans le code source HTML de la page. Quiconque peut afficher le code source de la page peut lire ces valeurs. Ce n’est pas une faille : c’est ainsi que fonctionnent les intégrations côté client. La sécurité ne vient pas du fait de cacher ces valeurs, mais de ce que fait le serveur lorsqu’il les reçoit.
Scénarios de sécurité
Site web public : accès ouvert
Mode : None. Origines : vos domaines.
L’assistant se charge sur toute origine autorisée sans clé. C’est la configuration la plus simple, et la bonne pour les centres d’aide publics, les pages produits et les sites marketing dont le contenu est déjà public. Limitez les origines à vos domaines pour empêcher quelqu’un d’intégrer votre assistant sur un site sans rapport.
Intranet ou site privé : accès légèrement restreint
Mode : API. Origines : vos domaines internes. Clé : générée.
La clé d’API sert d’identifiant public : elle indique au serveur quel assistant charger, mais ce n’est pas un secret. Associée à des origines autorisées restreintes, elle empêche la réutilisation opportuniste : l’assistant ne se charge que sur vos domaines, et uniquement avec la bonne clé. Quelqu’un qui copie la clé ne peut toujours pas utiliser l’assistant depuis une origine non autorisée.
C’est suffisant pour les outils internes, les environnements de préproduction et les sites dont l’audience est maîtrisée mais où une authentification formelle serait excessive.
Application authentifiée : accès lié à l’identité
Mode : OIDC. Origines : vos domaines. Issuer + audience : votre fournisseur.
L’intégration transmet un JWT de votre fournisseur d’identité (Firebase, Auth0, Azure AD, Okta, etc.) en tant que accessToken. Seekdown valide le jeton par rapport à l’issuer et à l’audience configurés avant d’autoriser l’assistant à répondre. Seuls les utilisateurs connectés via votre infrastructure d’authentification peuvent l’utiliser.
C’est la protection la plus forte, et le bon choix pour les tableaux de bord avec connexion, les portails clients et tout scénario où l’usage doit être lié à l’identité d’un utilisateur.
Comment les couches s’empilent
| Couche | Ce qu’elle contrôle | Visible dans le code source de la page ? |
|---|---|---|
| Mode d’authentification | Si un jeton est requis et comment il est validé. | Le mode lui-même est un réglage côté serveur, non exposé. |
| Origines autorisées | Quels domaines peuvent intégrer l’assistant. | Non : appliqué côté serveur. |
| Clé d’API | Identifie l’assistant en mode API. | Oui : elle figure dans l’extrait d’intégration. |
| Jeton OIDC | Prouve l’identité du visiteur en mode OIDC. | Le jeton est propre à la session, de courte durée et validé côté serveur. |
La clé d’API identifie quel assistant charger. Les origines autorisées contrôlent où il peut se charger. Le mode d’authentification contrôle qui peut l’utiliser. Ensemble, elles forment un modèle de sécurité pragmatique pour tous les scénarios, de l’accès entièrement ouvert à l’accès entièrement authentifié.