Ihren Assistenten absichern
Sicherheit besteht aus drei Ebenen, die zusammenwirken: dem Authentifizierungsmodus, der Liste der erlaubten Origins und – im API-Modus – dem API-Schlüssel. Wie Sie sie kombinieren, hängt davon ab, wer den Assistenten nutzen können soll.
Verstehen, was öffentlich ist
Wenn ein Assistent auf einer Website eingebettet ist, steht das Einbettungs-Snippet – einschließlich assistantId, accessToken (API-Schlüssel) und serviceURL – im HTML-Quelltext der Seite. Jeder, der den Seitenquelltext ansehen kann, kann diese Werte lesen. Das ist kein Fehler; so funktionieren clientseitige Einbettungen. Sicherheit entsteht nicht durch das Verstecken dieser Werte – sondern dadurch, was der Server tut, wenn er sie empfängt.
Sicherheitsszenarien
Öffentliche Website – offener Zugriff
Modus: None. Origins: Ihre Domains.
Der Assistent lädt auf jedem erlaubten Origin ohne Schlüssel. Das ist die einfachste Einrichtung und die richtige für öffentliche Hilfecenter, Produktseiten und Marketing-Websites, deren Inhalte ohnehin öffentlich sind. Beschränken Sie die Origins auf Ihre Domains, um zu verhindern, dass jemand Ihren Assistenten auf einer fremden Website einbettet.
Intranet oder private Website – leicht eingeschränkter Zugriff
Modus: API. Origins: Ihre internen Domains. Schlüssel: erzeugt.
Der API-Schlüssel dient als öffentliche Kennung – er sagt dem Server, welcher Assistent geladen werden soll, ist aber kein Geheimnis. In Kombination mit eingeschränkten erlaubten Origins verhindert das eine beiläufige Weiterverwendung: Der Assistent lädt nur auf Ihren Domains und nur mit dem richtigen Schlüssel. Wer den Schlüssel kopiert, kann den Assistenten trotzdem nicht von einem nicht autorisierten Origin aus nutzen.
Das reicht für interne Tools, Staging-Umgebungen und Websites, deren Publikum kontrolliert ist, für die eine formelle Authentifizierung aber übertrieben wäre.
Authentifizierte Anwendung – identitätsbasierter Zugriff
Modus: OIDC. Origins: Ihre Domains. Issuer + Audience: Ihr Anbieter.
Die Einbettung übergibt ein JWT Ihres Identitätsanbieters (Firebase, Auth0, Azure AD, Okta usw.) als accessToken. Seekdown validiert das Token gegen den konfigurierten Issuer und die Audience, bevor der Assistent antworten darf. Nur Nutzer, die sich über Ihren Auth-Stack angemeldet haben, können ihn verwenden.
Das ist der stärkste Schutz und die richtige Wahl für Dashboards mit Anmeldung, Kundenportale und jedes Szenario, in dem die Nutzung an eine Nutzeridentität gebunden sein soll.
Wie die Ebenen zusammenwirken
| Ebene | Was sie steuert | Im Seitenquelltext sichtbar? |
|---|---|---|
| Authentifizierungsmodus | Ob ein Token erforderlich ist und wie es validiert wird. | Der Modus selbst ist eine serverseitige Einstellung – nicht offengelegt. |
| Erlaubte Origins | Welche Domains den Assistenten einbetten dürfen. | Nein – serverseitig durchgesetzt. |
| API-Schlüssel | Identifiziert den Assistenten im API-Modus. | Ja – er steht im Einbettungs-Snippet. |
| OIDC-Token | Weist im OIDC-Modus die Identität des Besuchers nach. | Das Token gilt pro Sitzung, ist kurzlebig und wird serverseitig validiert. |
Der API-Schlüssel identifiziert, welcher Assistent geladen wird. Die erlaubten Origins steuern, wo er laden kann. Der Authentifizierungsmodus steuert, wer ihn nutzen kann. Zusammen bilden sie ein praxistaugliches Sicherheitsmodell für jedes Szenario – von völlig offen bis vollständig authentifiziert.