Zum Hauptinhalt springen
Laufzeitumgebungen für lokale Modelle wurden ursprünglich nicht für die Authentifizierung mehrerer Nutzer konzipiert. Ollama besitzt überhaupt keinen Mechanismus zur Verwaltung von API-Schlüsseln; seine Entwickler empfehlen stattdessen den Einsatz eines Reverse Proxys wie nginx oder Caddy. vLLM, llama.cpp sowie LM Studio bieten allenfalls 1 statische, optional nutzbare Schlüssel an. Tokios hingegen vergibt für jedes registrierte Modell individuelle, auf den Nutzer beschränkte sk-tok- Schlüssel – ohne dass Sie sich um Reverse Proxys, TLS-Zertifikate oder Firewall-Regeln kümmern müssen.

​
API-Schlüssel für Ollama – die kurze Antwort

Ollama kennt keine API-Schlüssel. Beim Ausführen von ollama serve akzeptiert die API unter http://localhost:11434 Anfragen von jedem, der Zugriff auf den entsprechenden Port hat. In Ollama selbst existieren weder ein --api-key-Flag noch eine Überprüfung über den Authorization-Header, und es gibt auch keine Nutzerbeschränkungen. Falls Sie steuern möchten, wer Ihr Ollama-Modell aufrufen darf, stehen Ihnen folgende 2 Optionen zur Verfügung:
  1. Reverse Proxy (nginx, Caddy): Hier können Sie HTTP-Basisauthentifizierung oder Token-Validierung vor Ollama einrichten. Sie selbst sind für die Konfiguration des Proxys, die TLS-Zertifikate sowie die Schlüsselrotation verantwortlich.
  2. Tokios Connector: Richten Sie einen Connector neben Ollama ein, registrieren Sie eine Deployment und erstellen Sie anschließend im Dashboard auf den Nutzer beschränkte sk-tok-…-Schlüssel. Dabei ist weder eine Proxy-Konfiguration noch TLS oder zusätzliche Eingangsports erforderlich. Weitere Informationen finden Sie unter Wie Tokios Schlüssel hinzufügt.

​
Was jede Laufzeitumgebung derzeit bietet

Dies stellt keineswegs ein Versäumnis dar – die genannten Laufzeitumgebungen wurden primär dafür entwickelt, Modelle bereitzustellen, nicht jedoch für die Steuerung von Zugriffsrechten in Multi-Tenant-Umgebungen. Genau diese Funktion stellt Tokios zusätzlich bereit. Gemäß den offiziellen Dokumentationen der jeweiligen Projekte: Keine dieser Methoden ermöglicht die Zuweisung individueller Schlüssel, die Einschränkung auf bestimmte Modelle oder das Widerrufen einzelner Zugriffsrechte ohne Beeinträchtigung anderer Nutzer. Genau diese Lücke schließt Tokios.

​
So fügt Tokios neue API-Schlüssel hinzu

Tokios fungiert als Vermittler zwischen Ihren Clients und der lokalen Laufzeitumgebung. Sobald der Connector konfiguriert und das Modell als Deployment registriert ist, erfolgt jede Anfrage mittels eines Tokios-API-Schlüssels – nicht mittels Schlüsseln von Ollama, vLLM, llama.cpp oder LM Studio.
1

Ihr Modell registrieren

Verknüpfen Sie zunächst den Connector und vergeben Sie Ihrem Modell einen öffentlichen Namen (das Deployment) im Tab Models. Falls Sie dies noch nicht getan haben, lesen Sie bitte Modell registrieren.
2

Einen Schlüssel im Reiter „Schlüssel“ erstellen

Öffnen Sie den Tab Keys und klicken Sie auf Create key. Geben Sie dem Schlüssel einen Anzeigenamen sowie optional Einschränkungen mittels model patterns – dabei handelt es sich um durch Kommas getrennte Platzhalter wie gemma*, gpt-4* –, sodass er nur auf gewünschte Deployments zugreifen kann. Lassen Sie es bei *, um Zugriff auf alle Modelle zu gewähren.
3

Den Schlüssel kopieren

Der Schlüssel wird nur einmal als sk-tok-... angezeigt. Kopieren Sie ihn umgehend und speichern Sie ihn in einem Passwort-Manager oder Geheimnisspeicher. Sie dürfen bis zu 50 aktive Schlüssel verwalten; jeder davon lässt sich später bearbeiten, austauschen, deaktivieren oder löschen.
4

Anfragen authentifizieren

Senden Sie den API-Schlüssel als Bearer-Token im Authorization-Header:
Die vollständigen Vorgänge zum Erstellen, Rotieren und Zurückziehen von API-Schlüsseln finden Sie unter API-Schlüssel.

​
Weisen Sie jedem Teammitglied sowie jedem Dienst einen eigenen API-Schlüssel zu.

Da ein gemeinsam genutzter statischer API-Schlüssel – oder gar kein API-Schlüssel – keine Unterscheidung zwischen verschiedenen Anrufern ermöglicht, sollten Tokios-API-Schlüssel genauso behandelt werden wie jede andere Zugangsdaten, die an mehrere Personen weitergegeben werden:
  • Ein API-Schlüssel pro Person oder Umgebung. Erstellen Sie für jedes Teammitglied, jeden CI-Prozess sowie jeden Dienst einen separaten API-Schlüssel. Sollte jemand das Team verlassen oder ein Laptop verloren gehen, deaktivieren Sie einfach diesen API-Schlüssel im Bereich Keys – alle anderen können weiterarbeiten.
  • Begrenzen Sie den API-Schlüssel auf die benötigten Modelle. Definieren Sie für jeden API-Schlüssel spezifische Modellmuster. Ein API-Schlüssel, der auf gemma* beschränkt ist, kann keinen Zugriff auf eine gpt-4*-Deployment erhalten, selbst wenn beide hinter demselben Connector laufen.
  • Ein kompromittierter API-Schlüssel gelangt nicht zu anderen Mandanten. API-Schlüssel sind auf Ihr Konto sowie optional auf bestimmte Deployments beschränkt; folglich kann ein kompromittierter API-Schlüssel nicht auf Modelle zugreifen, die nicht explizit dafür freigegeben wurden.
Die schnellste Methode, jemandem einen speziell konfigurierten API-Schlüssel zuzuweisen, ist das Erstellen unter Share Key im Bereich „API-Schlüssel“ – dabei wird ein individueller API-Schlüssel erzeugt und der Empfänger erhält per E-Mail einen einmalig gültigen Freischaltlink (der API-Schlüssel selbst erscheint dabei nie im Text). Zudem lässt sich ein Modellbereich, ein optionales Passwort sowie ein Ablaufdatum festlegen; außerdem kann der API-Schlüssel per Klick zurückgezogen werden. Weitere Informationen finden Sie unter API-Schlüssel per E-Mail teilen.
Versucht ein API-Schlüssel, eine Deployment aufzurufen, zu der er keinen Zugriff besitzt, lehnt Tokios die Anfrage mit HTTP 403 ab:
Ein Wert von 403 signalisiert, dass der API-Schlüssel das jeweilige Modell nicht nutzen darf (oder das Konto gesperrt ist); ein Wert von 404 bedeutet, dass die angegebene Deployment nicht existiert. Die vollständige Liste finden Sie unter API-Endpunkte.
Rotieren Sie einen API-Schlüssel genauso wie jede andere Zugangsdaten: Erstellen Sie einen Ersatz, aktualisieren Sie die jeweiligen Aufrufer und deaktivieren Sie anschließend den alten API-Schlüssel, sobald der gesamte Datenverkehr umgeleitet wurde.

​
Was kommt als Nächstes?

Ein API-Schlüssel lässt sich nicht direkt in Ollama erzeugen, da dieses kein Schlüsselmechanismus besitzt. Um Authentifizierung vor Ollama zu ermöglichen, nutzen Sie Tokios: Erstellen Sie dort einen Schlüssel auf der Keys-Registerkarte, kopieren Sie den Wert von sk-tok-… und übergeben Sie ihn als Authorization: Bearer sk-tok-YOUR_KEY in Ihren API-Anfragen. Tokios übernimmt die Authentifizierung, Berechtigungszuweisung sowie das Widerrufen von Schlüsseln.
vLLM unterstützt beim Start des Servers den statischen 1---api-key-Parameter (zum Beispiel vllm serve model --api-key my-key). Dieser stellt einen einzigen gemeinsamen Schlüssel für alle Nutzer dar; laut offiziellen Sicherheitsrichtlinien sollte man sich jedoch nicht ausschließlich darauf verlassen. Für individuelle Nutzer-Schlüssel empfiehlt sich die Integration von Tokios.
Der llama.cpp-Server akzeptiert optional den --api-key-Parameter, doch dieser stellt lediglich einen allgemeinen Schlüssel ohne Nutzerzuweisung bereit. Mit Tokios erhält jede Person oder jedes Dienstprogramm einen eigenen sk-tok-…-Schlüssel, der auf spezifische Modelle beschränkt ist.

API-Schlüssel

Ausführliche Erläuterungen zur Erstellung, Zuweisung, Rotation sowie zum Widerrufen von Schlüsseln.

Schnellstart

Verknüpfen Sie einen Connector, registrieren Sie ein Modell und senden Sie anschließend Ihre erste authentifizierte Anfrage.

Modell registrieren

Vergeben Sie Ihrem lokalen Modell einen öffentlichen Namen, den Clients anschließend nutzen können.

Fernzugriff auf Ollama

Sie können auf eine Ollama-Instanz von einem anderen Rechner aus zugreifen, ohne eingehende Ports öffnen zu müssen.