Die 4 wichtigen CLI-Auth-Methoden, wie GitHub, AWS und KI-Tools sie implementieren und welche Sicherheitsfehler du vermeiden solltest.
Jeder Entwickler-CLI liefert login als ersten Befehl. Und jeder löst Auth anders.
GitHub zeigt dir einen Code und öffnet deinen Browser zur Verifizierung. AWS öffnet einen Browser für PKCE-basiertes SSO. Stripe lässt dich einen Kopplungscode im Dashboard bestätigen. Die neueren KI-Tools (Claude Code, OpenAI Codex CLI, Cursor) haben jeweils ihren eigenen Ansatz gewählt.
Wenn du eine CLI entwickelst, ist Auth eine der ersten Dinge, die du klären musst. Wählst du die falsche Methode, bekommst du es zu spüren: frustrierte Nutzer, Audits oder beides. Und mit der neuen Welle von KI-Codierungsagenten, die CLI-Tools programmatisch ansprechen, steht noch mehr auf dem Spiel: Du authentifizierst nicht mehr nur einen Menschen. Möglicherweise übergibst du Zugangsdaten an einen autonomen Prozess.
Hier sind die vier Auth-Methoden, die wirklich zählen, wie die wichtigsten Tools sie implementieren und welche Fehler du vermeiden solltest.
Bevor wir tief einsteigen, hier der schnelle Vergleich:
| Methode | Am besten geeignet für | Sicherheit | Braucht Browser? |
|---|---|---|---|
| OAuth Device Code Flow | Headless-Umgebungen, SSH | Hoch | Nein (auf demselben Gerät) |
| Browserbasierte OAuth (localhost redirect) | Lokale Entwicklung | Sehr hoch | Ja |
| API-Schlüssel / PATs | Automatisierung, CI/CD, schnelles Prototyping | Mittel | Nein |
| Client Credentials | Machine-to-Machine, Services | Hoch | Nein |
Jede Methode hat Vor- und Nachteile. Hier ist, was du über jede wissen solltest.
Das ist die Methode, bei der deine CLI einen Code wie ABCD-1234 und eine URL zeigt und dir sagt, du sollst diese URL auf einem beliebigen Gerät öffnen und den Code eingeben.
Wer nutzt es: GitHub CLI (standardmäßig), Azure CLI (mit --use-device-code), Vercel CLI (kürzlich als Standard umgestellt), OpenAI Codex CLI (als Beta-Option)
cli login ausclient_id und den gewünschten Scopesdevice_code (interne Kennung), einen user_code (den kurzen Code, den du eingibst) und eine verification_uri (wohin du gehst)Das große Argument: Es funktioniert überall. SSH-Session auf einen Remote-Server? Geht. Läuft in einem Docker-Container? Geht. Cloud-IDE ohne lokalen Browser? Geht. Der Browser muss nicht auf demselben Gerät wie die CLI sein.
Außerdem unterstützt es jegliche Enterprise-Authentifizierung (SAML, OIDC, MFA), weil all das im Browser stattfindet, nicht im Terminal. Die CLI sieht nie dein Passwort.
Device Code Flow hat ein Phishing-Problem. Ein Angreifer kann eine Device-Code-Anfrage starten, einen echten User-Code erhalten und dich dazu bringen, ihn einzugeben – und so die Sitzung des Angreifers autorisieren. Das ist nicht nur theoretisch. Sicherheitsforscher haben diesen Angriff für AWS SSO Device-Code-Auth dokumentiert.
Das Problem ist so groß, dass AWS den Standard geändert hat. Ab AWS CLI v2.22.0 ist der Standard für aws sso login von Device-Code-Flow auf PKCE-basierte Authorization-Code-Flow umgestellt. Device Code kann immer noch via --use-device-code genutzt werden, ist aber nicht mehr der Standard.
Unterdessen beginnt Microsoft in seiner eigenen Tenant, Device-Code-Flow komplett zu blockieren – ein starkes Signal, dass es als Hochrisiko-Authentifizierungsmethode betrachtet wird.
Das ergibt ein interessantes Bild: Vercel hat Device-Code-Flow im September 2025 als Standard eingeführt, während AWS davon weggeht. Das Muster: Device-Code-Flow ist ideal, wenn man wirklich keinen Browser öffnen kann, aber falls ein lokaler Browser möglich ist, ist PKCE sicherer.
Auf der Seite der Auth-Anbieter steigt die Nachfrage deutlich. Logto hat vor Kurzem OAuth 2.0 Device Authorization Grant für native Apps in v1.38.0 (Open Source) und Logto Cloud ausgeliefert, sodass du jetzt Device-Flow als Autorisierungsmethode für jede native Anwendung aktivieren kannst. Das ist wichtig, wenn du eine CLI baust. Die korrekte Implementierung von RFC 8628 (Ablaufzeit, Rate-Limit, Polling-Logik, UX auf der Verifizierungsseite) ist mehr Aufwand, als die meisten Teams denken. Wenn dein Auth-Provider das übernimmt, musst du nur die richtigen HTTP-Calls machen.
Wissenswertes aus RFC 8628:
expires_in-Wert für Device-Codes wird vom Auth-Server gesetzt. Das RFC nimmt 1800 Sekunden (30 Minuten) als Beispiel, aber das ist keine feste Vorschrift.interval vorgibt, müssen Clients standardmäßig 5 Sekunden verwenden.slow_down-Fehler: 5 Sekunden zum Intervall hinzufügen.Das ist die häufigste Methode für CLIs auf dem lokalen Entwicklerrechner. Du führst login aus, der Browser öffnet sich, du authentifizierst dich und der Browser leitet zurück zu einem lokalen Server, den die CLI temporär aufgesetzt hat. Moderne Implementierungen fügen PKCE (ausgesprochen "Pixie") hinzu, was die Methode deutlich absichert.
Wer nutzt es: Claude Code, gcloud CLI, Terraform CLI, AWS CLI v2.22+ (für SSO, standardmäßig mit PKCE)
cli loginhttp://127.0.0.1:8742)http://127.0.0.1:8742/callback?code=XXXX&state=YYYYDas Nutzererlebnis ist durchgängig. Keine Codes zum Kopieren, keine URLs zum Eintippen. Nur ein Browser-Tab, der aufgeht und sich wieder schließt.
Das klappt nur, wenn die CLI einen Browser aufrufen und an Localhost binden kann. Ausgeschlossen sind:
Deshalb bieten die meisten Tools, die standardmäßig auf Browser-OAuth setzen, einen Fallback, i.d.R. Device-Code-Flow oder API-Schlüssel.
Lücke 1: Auf 0.0.0.0 statt 127.0.0.1 binden
Typischer Fehler – und gravierend. Wenn dein Callback-Server auf allen Interfaces lauscht, kann jeder im gleichen Netz den Auth-Code abfangen.
Das passiert in der Praxis und ist leicht übersehen, weil viele HTTP-Server-Libraries als Standard 0.0.0.0 verwenden.
Lücke 2: Keine State-Parameter-Validierung
Der state-Parameter ist dein CSRF-Schutz. Ohne ihn kann ein Angreifer deine CLI dazu bringen, einen Auth-Code von einer fremden Sitzung anzunehmen.
Lücke 3: PKCE fehlt
Wenn dein OAuth-Flow kein PKCE (Proof Key for Code Exchange) nutzt, kann ein Authorization-Code abgefangen und wiederverwendet werden.
Im Standard-Autorisierungs-Flow kann ein Angreifer, der den Code abfängt (im Netzwerk oder durch das Mitlesen der Redirect-URL), diesen zum Token-Tausch nutzen. PKCE verhindert das, indem ein Nachweis (code_verifier) verlangt wird, der beim Austausch vorgelegt werden muss.
So erweitert PKCE den Flow:
code_verifiercode_challenge durch Hashen mit SHA-256code_verifierEin Angreifer, der nur den Code abfängt, kann ohne Verifier den Token-Tausch nicht abschließen.
Deshalb ist PKCE seit AWS CLI v2.22+ Standard für SSO – und Device-Code-Flow nicht mehr. Wo ein Browser lokal verfügbar ist, ist Browser-OAuth mit PKCE besser als Device-Code-Flow: Gleiches UX, bessere Sicherheit, keine Phishing-Lücke. Device-Code-Flow bleibt richtig, wenn kein Browser auf dem selben Gerät verfügbar ist (SSH, Container, Remote-Dev), aber das ist im Alltag selten.
Der einfachste Ansatz. Du erzeugst im Web-Dashboard einen Token, fügst ihn in die CLI-Konfiguration oder eine Umgebungsvariable ein – fertig.
Wer nutzt es: Stripe CLI (als Anmeldeoption), npm, pip, die meisten KI-Coding-Tools als Fallback (Claude Code via ANTHROPIC_API_KEY, OpenAI Tools via OPENAI_API_KEY, Aider)
sk_live_, ghp_, npm_)~/.config/stripe/config.toml, ~/.aws/credentials) oder einer Umgebungsvariable speichernDie CLI liest ihn beim Start ein und schickt ihn typischerweise als Bearer-Token im Authorization-Header mitz.
Für Automatisierung sind API-Schlüssel kaum zu schlagen. Sie funktionieren im CI/CD, in Containern, Skripten, Cronjobs. Überall, wo eine Umgebungsvariable gelesen werden kann. Kein Browser notwendig. Keine Interaktion. Kein Token-Refresh-Prozess.
Im KI-Agent-Workflow sind API-Schlüssel geradezu prädestiniert. Wenn Claude Code oder Cursor eine API aufrufen müssen, ist die Umgebungsvariable mit Schlüssel der einfachste Weg.
Die clevere Lösung: API-Schlüssel gegen kurzlebige Tokens zur Laufzeit eintauschen.
AWS war hier Vorreiter mit STS (Security Token Service): Die langfristigen Zugangsdaten werden nur für einen temporären Satz Credentials verwendet (meist 1 Stunde gültig). Tools wie aws-vault automatisieren das.
Auch wenn du mit API-Schlüsseln startest: Baue den Token-Tausch ein, um die Risiken bei Key-Diebstahl von "unbegrenzt" auf "eine Stunde" zu senken.
Dieser OAuth-2.0-Flow ist für Service-zu-Service-Authentifizierung gedacht: Maschinen reden mit Maschinen, kein Mensch ist involviert.
Eingesetzt bei: CI/CD-Pipelines, Background-Services, automatisierten Tools
Der Service sendet client_id und client_secret direkt an den Auth-Server und erhält ein kurzlebiges Access-Token. Kein Browser, keine Nutzerinteraktion, kein Redirect.
Client Credentials Flow ist geeignet wenn:
Nicht für Menschen verwenden! Keine MFA, kein SSO, keine interaktive Prüfung.
Hier eine korrigierte Übersicht laut aktueller Dokumentation und Quellcode. Viele Artikel liegen falsch, weil Tools ihre Defaults ändern.
| CLI-Tool | Standard-Auth | Fallbacks | Token-Speicher |
|---|---|---|---|
GitHub CLI (gh) | Device-Code-Flow via Browser | PAT (--with-token), Env Var (GH_TOKEN) | Betriebssystem-Schlüsselbund (Fallback: Klartext-Datei) |
| AWS CLI v2 | PKCE-Auth-Code-Flow (SSO) | Device-Code (--use-device-code), Credential-Files | ~/.aws/sso/cache/ |
Azure CLI (az) | WAM unter Windows; Browser-Auth-Code-Flow unter Linux/macOS | Device-Code (--use-device-code) | ~/.azure/msal_token_cache.* |
| Vercel CLI | Device-Code-Flow (neuer Standard, Sep 2025) | API-Token (--token, Env Var) | ~/.local/share/com.vercel.cli/auth.json |
| Stripe CLI | Browserbasiertes Pairing | API-Key (--interactive, --api-key oder Env Var) | ~/.config/stripe/config.toml |
| gcloud CLI | Browser-OAuth | --no-browser manueller Flow | ~/.config/gcloud/ |
| Claude Code | Browser-OAuth | API-Key (Env Var, apiKeyHelper) | Betriebssystem-Schlüsselbund / ~/.claude/.credentials.json |
| OpenAI Codex CLI | Browser-OAuth | Device-Code (beta), API-Key | ~/.codex/auth.json / Betriebssystem-Keyring |
| Terraform CLI | Browser-OAuth | Token einfügen | ~/.terraform.d/credentials.tfrc.json |
Der Trend ist klar: Browserbasierte OAuth ist Standard für lokale Entwicklung, Device-Code-Flow die Headless-Alternative, API-Keys die Lösung für Automatisierung. PKCE wird dort Standard, wo ein Browser verfügbar ist.
Auth nützt nichts, wenn Tokens falsch gespeichert werden.
Jedes größere OS hat einen eingebauten sicheren Credential-Speicher:
Diese bieten Verschlüsselung, Zugriffskontrolle und ggf. Hardware-Security. Deine CLI muss keine eigene Kryptografie implementieren.
Wo kein Keychain verfügbar ist (Container, Minimal-Linux), verschlüsselte Config-Files mit restriktiven Berechtigungen:
Klartextdateien. Sollte klar sein, aber viele Tools machen es noch. Eine Token-Textdatei ist jedem Prozess zugänglich, landet in Backups und kann bei temporärem Zugriff entwendet werden.
Umgebungsvariablen für Dauerhafte Speicherung. Sie sind in Prozesslisten sichtbar, werden häufig geloggt, gehen an Kind-Prozesse über. Für CI/CD ok (da wird das von der Plattform gehandhabt), aber lokal riskant.
Browser localStorage. Falls deine CLI eine Web-Komponente hat, speicher Tokens nicht in localStorage. Ein XSS und alles ist offen.
Kurzlebig halten. Eine Stunde ist Standard. Nach Ablauf sollte die CLI automatisch erneuern, nicht den Nutzer belästigen.
Langlebige Zugangsdaten zum Erneuern von Access-Tokens ohne erneute Authentifizierung. Wichtige Ziele für Angreifer, weil sie (Tage bis Monate) länger leben.
Moderne Auth-Systeme rotieren Refresh-Tokens bei jeder Nutzung:
So wird der Schaden eines gestohlenen Refresh-Tokens begrenzt. Wird ein Refresh-Token mehrfach benutzt (Angreifer/Nutzer), erkennt das der Auth-Server und löscht die gesamte Token-Familie: Beider Zugriff ist gesperrt, erneute Authentifizierung wird nötig, aber dauerhafter Zugriff des Angreifers verhindert.
Siehe oben – immer 127.0.0.1, niemals 0.0.0.0.
Passiert öfter, als zugegeben wird. Ein Debug-Log, ein Error-Handler, ein "verbose"-Modus ...
Docker-Images sind keine Geheimnisspeicher. Jeder Layer ist extrahierbar.
Wenn ein Token während einer Operation ausläuft, nicht einfach mit 401 Fehler abbrechen. Erst Refresh versuchen und nur zur Login-Aufforderung, falls auch der Refresh ausgelaufen ist.
Nicht admin:*-Scope anfragen, wenn repo:read genug ist. Gilt für OAuth-Scopes und API-Key-Berechtigungen.
Gerade wenn ein KI-Agent deine CLI nutzt, ist das wichtig. Du willst vermutlich nicht, dass ein Assistent sofort Löschrechte hat, nur weil er Leserechte braucht.
Was macht 2026 anders als 2023? CLIs sind nicht mehr nur für Menschen am Terminal. KI-Codierungsagenten wie Claude Code, Codex und Cursor-Agents sprechen CLIs programmatisch an – und das stellt neue Auth-Herausforderungen:
Delegierte Rechte. Führt Claude Code z.B. gh pr create für dich aus, nutzt er deine GitHub-Zugangsdaten. Aber sollte ein Agent dieselben Rechte haben? Prinzip der minimalen Rechte sagt nein – aber die meisten Tools können Agenten-Rechte nicht granular einschränken.
Credential Exposure. Liegen API-Keys als Umgebungsvariable vor, kann jeder Prozess sie lesen – auch Subprozesse des KI-Agenten. Claude Code hat z.B. apiKeyHelper-Skripte eingeführt, die zur Laufzeit Kurzzeittoken erzeugen. Das ist aber noch kein Standard.
Headless-Auth für Agenten. Ein KI-Agent in einer Sandbox-Umgebung kann keinen Browser öffnen. Device-Code-Flow funktioniert (der Mensch gibt auf anderem Gerät frei), aber API-Keys sind üblicher, da kein Mensch eingreifen muss.
Audit-Trails. Macht ein Agent API-Calls mit deinen Credentials, erscheinen die Logs so, als hättest du sie gemacht. Es gibt bisher keinen Standard, um Mensch und Agent zu trennen.
Das Feld entwickelt sich. Aktueller Best-Practice:
Welche Auth-Methode wählen? Kurzfassung:
"Meine Nutzer sind Entwickler auf ihren lokalen Rechnern" → Browser-OAuth mit PKCE (beste Sicherheit + smoothes UX)
"Meine CLI muss auch per SSH und in Containern funktionieren" → Device-Code-Flow als Fallback, Browser-OAuth als Standard
"Läuft komplett CI/CD, keine Menschen im Loop" → Client Credentials Flow oder verweiste API-Keys
"Muss schnell fertig werden" → API-Keys (aber später Token-Rotation nachrüsten)
"Enterprisekunden brauchen SSO und MFA" → Beliebiger OAuth-Flow (Device-Code oder Browser), unterstützt alle Enterprise-Auth-Lösungen
"KI-Agenten nutzen die CLI" → API-Keys anbieten (einfache Agent-Integration) + Browser-OAuth (für Menschen), tokens gescoped und kurzlebig
Ziemlich sicher gegen die meisten Angriffe, aber nicht gegen Phishing: Ein Angreifer kann einen Device-Code erzeugen und Nutzer reinlegen. Darum setzt AWS für SSO jetzt auf PKCE. Für Headless-Umgebungen ist Device-Code-Flow aber weiter die beste Option – du solltest nur das Phishing-Risiko kennen.
Im CI/CD: ja, weil die Plattform sie verschlüsselt und erst zur Laufzeit einblendet. Lokal: nein. Lieber Betriebssystem-Keychain. Env-Vars sind in Prozesslisten sichtbar und könnten versehentlich geloggt werden.
Funktional fast nichts. Beide sind langlebige Zugangsdaten. Der Unterschied ist meist nur organisatorisch: API-Schlüssel meist für ein Projekt/Service, PATs an Nutzeraccount gebunden. Die Begriffe werden teils synonym verwendet.
Access-Tokens: Automatisch, etwa jede Stunde (über Refreshtoken). Refresh-Tokens: Am besten bei jeder Nutzung (sollte der Auth-Server machen). API-Keys: Alle 90 Tage mindestens oder sofort bei Verdacht auf Leck. Praktisch rotieren Teams meist erst nach Vorfall – zu spät.
Drei Wege, nach Präferenz:
docker run -e API_KEY=${API_KEY}) im CI/CDdocker run -v ~/.config/tool:/root/.config/tool:ro) für lokale EntwicklungNiemals Zugangsdaten ins Image einbacken. Niemals.
MCP ist der neue Standard, damit KI-Agenten mit externen Tools/Diensten sprechen können. Das führt zu einer neuen Auth-Ebene: Der Agent braucht Creds für den MCP-Server, dieser wiederum für Downstream-APIs. Das entwickelt sich gerade – aktuell wird meist ein API-Key oder OAuth-Token in die MCP-Konfiguration gegeben. Hier wird sich noch viel tun.
CLI-Authentifizierung ändert sich schnell. Was vor zwei Jahren als Best Practice galt (Device-Code-Flow als Standard, Klartext-Dateien für Credentials), ist schon überholt. Wenn du jetzt Auth für eine CLI baust, beginne mit Browser-OAuth + PKCE für Menschen, API-Keys für Automatisierung und plane dafür, dass irgendwann KI-Agenten deine Hauptnutzer sind.