Auth- und Zugangsdaten-Semantik

Ein sauberes OpenClaw-Setup braucht zwei getrennte Fragen direkt am Anfang. Wer darf die Aktion ausführen, und welches konkrete Secret oder Token beweist das?

Wenn du beides vermischst, bekommst du Credential-Sprawl. Das ist die digitale Version davon, Haus-, Büro- und Autoschlüssel in dieselbe Schale zu werfen und zu hoffen, dass schon die richtige Person das Richtige erwischt. Manchmal klappt das. Meistens genau so lange, bis es wichtig wird.

Die offizielle Authentifizierungs-Referenz und der Guide zu Auth Credential Semantics sind die zwei OpenClaw-Seiten, die du für dieses Thema zusammen lesen solltest.

Die drei Auth-Ebenen, die ständig durcheinandergeraten

OpenClaw hat mehr als eine Auth-Oberfläche. Das ist hilfreich, aber nur dann, wenn du die Ebenen im Kopf sauber trennst.

• Gateway-Zugriff: wer sich überhaupt mit dem Gateway verbinden darf
• Provider-Auth: wie OpenClaw mit Modell-Providern wie OpenAI oder Anthropic spricht
• Session- oder Agent-Routing: welches gespeicherte Profil ein bestimmter Agent oder Chat nutzen soll

Diese Ebenen hängen zusammen, sind aber nicht austauschbar. Ein gesundes Gateway kann trotzdem ein kaputtes Provider-Profil haben. Ein funktionierender Provider-Login kann trotzdem an den falschen Chat geroutet werden. Das Problem ist oft nicht fehlende Auth, sondern falsch platzierte Auth.

Was Zugangsdaten-Semantik hier eigentlich bedeutet

Semantik klingt erst einmal trocken. Gemeint sind hier schlicht die Regeln, die entscheiden, ob ein Credential gültig, zulässig und tatsächlich ausgewählt ist.

OpenClaw behandelt nicht jedes gespeicherte Token automatisch als gleich gut nutzbar. Abgelaufene Credentials, kaputte Expiry-Werte, ungelöste Refs oder Profile, die durch Auth-Reihenfolge ausgeschlossen sind, sollten nicht still gewinnen, nur weil sie existieren.

Das klingt selbstverständlich. Genau hier kippen unordentliche Setups aber regelmäßig um. Jemand speichert drei Profile, vergisst, welches aktiv ist, und hofft, dass Magie den Rest erledigt. Magie ist eine schlechte Operator-Strategie.

OAuth versus statische Zugangsdaten

Das ist die praktisch wichtigste Trennung, bevor du irgendetwas anfasst.

Statische Zugangsdaten

API-Keys und feste Tokens sind die vorhersehbare Variante für dauerhaft laufende Hosts. Sie lassen sich gezielter rotieren, sauberer überwachen und nach einem schiefen Deploy meist leichter wieder geradeziehen.

OAuth-Zugangsdaten

OAuth ist sinnvoll, wenn das Konto-Modell des Providers darauf ausgelegt ist oder wenn OpenClaw einen freigegebenen Login-Reuse-Flow dafür unterstützt. Der Preis ist mehr Komplexität. Access Tokens laufen ab, Refresh Tokens können rotieren, und das Kopieren zwischen Agenten erzeugt schnell genau die Art von rätselhaftem Logout, auf die niemand Lust hat.

Die praktische Regel ist simpel: Nutze API-Keys für langweilige, stabile Infrastruktur, und nutze OAuth dann, wenn der Produkt-Flow davon wirklich profitiert.

# Prüfen, was OpenClaw gerade wirklich nutzen kann
openclaw models status
openclaw models status --probe

# Automationen hart fehlschlagen lassen, wenn Auth fehlt oder abgelaufen ist
openclaw models status --check

# Provider-Login setzen oder ersetzen
openclaw models auth login --provider openai
openclaw models auth login --provider anthropic --force

Warum Profil-Routing wichtiger ist, als es zuerst wirkt

Ein Credential zu speichern ist nur die halbe Arbeit. Du musst auch steuern, wann dieses Profil zulässig ist und wann es tatsächlich gewinnen soll.

OpenClaw gibt dir dafür ein paar Hebel:

• auth.order: legt die Priorität von Profilen pro Provider fest
• Session-Pinning pro Modell: lässt einen einzelnen Chat ein bestimmtes Profil nutzen
• Getrennte Agenten: halten Arbeits- und Privat-Credentials voneinander fern

Getrennte Agenten sind oft die vernünftigere Wahl. Ja, das wirkt am ersten Tag etwas schwerer. Zwei Monate später, wenn das falsche Konto belastet wird, wirkt es plötzlich sehr leicht.

# Beispiel: ein Provider-Profil an eine Session pinnen
/model Opus@anthropic:work

# Beispiel: Auth-Reihenfolge für einen Agenten setzen
openclaw models auth order set --provider anthropic anthropic:default
openclaw models auth order get --provider anthropic

Wie Secret Sprawl beginnt

Secret Sprawl startet selten mit Nachlässigkeit. Meist startet er mit Bequemlichkeit.

• Du trägst schnell einen Key direkt in die Config ein, weil es eilig ist
• Du lässt ein altes OAuth-Profil "für alle Fälle" liegen
• Du kopierst ein Profil in einen anderen Agenten, ohne Eigentümerschaft und Refresh-Flow zu klären
• Du benennst Profile nicht mehr sauber, weil du glaubst, dich später schon zu erinnern

Später kommt, die Erinnerung nicht, und plötzlich hat dein Setup die emotionale Qualität einer überfüllten Kramschublade.

Die Lösung ist nicht mehr Heldentum. Die Lösung sind bessere Grenzen. Halte Auth-Profile benannt, eng gefasst und bewusst gewählt. Trenne statische Secret-Ablage von Routing-Metadaten. Halte Agenten getrennt, wenn Konten sich nie berühren sollten.

Operator-Schutzgeländer, die dich vor dir selbst retten

OpenClaw liefert bereits die Rohstoffe für sicherere Auth-Abläufe. Nutze sie, bevor du dir ein eigenes Ritual zusammenbastelst.

1. Erst prüfen, dann rätseln: openclaw models status --probe zeigt, warum ein Profil übersprungen wird oder scheitert
2. Benannte Profile bevorzugen: default ist einmal okay, danach wird es schnell vage
3. Getrennte Agenten für getrennte Konten nutzen: besonders bei Arbeit versus privat
4. Kopierte OAuth-Daten standardmäßig misstrauisch behandeln: Rotationsregeln machen Wiederverwendung oft fragil
5. Secrets aus allgemeiner Config heraushalten: echtes Secret-Material gehört in saubere Ablage und Referenzen

Das ist ein bisschen wie Schlüsselverwaltung in einem echten Gebäude. Je weniger Generalschlüssel lose herumliegen, desto geringer ist die Chance, dass dir ein Problem erst auffällt, nachdem schon jemand mit einem davon verschwunden ist.

Wenn etwas kaputt wirkt, aber eigentlich nur falsch geroutet ist

Einer der häufigsten Auth-Fehler ist die Annahme, der Provider sei gestört, obwohl in Wahrheit die Auswahl-Logik danebenliegt.

• Ein gespeichertes Profil existiert, wird aber durch Auth-Reihenfolge ausgeschlossen
• Ein Token ist da, aber die Expiry-Metadaten machen ihn unzulässig
• Eine Session nutzt weiter ein altes gepinntes Profil, bis du sie zurücksetzt
• Ein vererbtes Agent-Profil funktioniert zur Laufzeit, obwohl du einen eigenen lokalen Login erwartet hast

Genau deshalb ist Semantik wichtig. Sie hält die Diagnose an Regeln fest statt an Bauchgefühl.

Die Kurzfassung

• Trenne Gateway-Auth, Provider-Auth und Profil-Routing sauber im Kopf
• Nutze statische Zugangsdaten für langweilige, stabile Hosts, wenn möglich
• Nutze OAuth bewusst und nicht beiläufig, besonders über mehrere Agenten hinweg
• Benenne und begrenze Auth-Profile so, dass Auswahl verständlich bleibt
• Nutze Probe- und Status-Befehle, bevor du rätst, wo Auth scheitert

Das Ziel ist nicht, jeden Randfall auswendig zu kennen. Das Ziel ist, deine Credential-Story so einfach zu halten, dass dein zukünftiges Ich keine Detektivarbeit braucht, nur um zu verstehen, wer wo eingeloggt ist.