CLI-Authentifizierung richtig machen: Der vollständige Leitfaden zu allen 4 Methoden

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.

Die vier Methoden im Überblick#

Bevor wir tief einsteigen, hier der schnelle Vergleich:

Jede Methode hat Vor- und Nachteile. Hier ist, was du über jede wissen solltest.

1. OAuth Device Code Flow (RFC 8628)#

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)

Wie es funktioniert#

1. Du führst cli login aus
2. Die CLI fordert einen Device-Code vom Auth-Server an, mit ihrem client_id und den gewünschten Scopes
3. Der Server gibt drei Dinge zurück: einen device_code (interne Kennung), einen user_code (den kurzen Code, den du eingibst) und eine verification_uri (wohin du gehst)
4. Deine CLI zeigt den Code und die URL an und beginnt dann, den Auth-Server alle 5+ Sekunden abzufragen
5. Du öffnest die URL auf jedem Gerät (Handy, Laptop, ein anderer Computer), gibst den Code ein und authentifizierst dich mit Methode deiner Wahl (Passwort, SSO, Passkeys, MFA)
6. Nach deiner Bestätigung gibt die nächste Abfrage ein Access- und ein Refresh-Token zurück
7. Die CLI speichert diese und du bist drin

Warum Entwickler es mögen#

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.

Der unterschätzte Sicherheits-Haken#

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.

Technische Details aus dem RFC#

Wissenswertes aus RFC 8628:

• Der 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.
• Falls der Server kein Polling-interval vorgibt, müssen Clients standardmäßig 5 Sekunden verwenden.
• slow_down-Fehler: 5 Sekunden zum Intervall hinzufügen.
• Device-Codes sollten Einmalcodes und schnell ablaufend sein.
• Alle Token-Austausche müssen über HTTPS laufen.

2. Browserbasierte OAuth (localhost redirect)#

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)

Wie es funktioniert#

1. Du lädst cli login
2. Die CLI startet einen temporären HTTP-Server auf einem zufälligen lokalen Port (z.B. http://127.0.0.1:8742)
3. Sie öffnet deinen Standardbrowser mit dem Authanbieter-Endpunkt und gibt die Localhost-URL als redirect_uri mit
4. Du authentifizierst dich im Browser (SSO, Passwort, Passkey, was auch immer der Anbieter unterstützt)
5. Der Authanbieter leitet zurück auf http://127.0.0.1:8742/callback?code=XXXX&state=YYYY
6. Der lokale Server fängt den Authorization-Code ab, tauscht ihn via Backend-HTTPS gegen Tokens
7. Im Browser erscheint "Erfolg! Du kannst dieses Tab schließen"
8. Die CLI speichert die Tokens und fährt den lokalen Server wieder runter

Das Nutzererlebnis ist durchgängig. Keine Codes zum Kopieren, keine URLs zum Eintippen. Nur ein Browser-Tab, der aufgeht und sich wieder schließt.

Wann das nicht funktioniert#

Das klappt nur, wenn die CLI einen Browser aufrufen und an Localhost binden kann. Ausgeschlossen sind:

• SSH-Sessions auf entfernten Servern
• Docker-Container (außer mit Portforwarding-Tricks)
• CI/CD-Pipelines
• Headless-Server
• Manche restriktiven Unternehmensumgebungen

Deshalb bieten die meisten Tools, die standardmäßig auf Browser-OAuth setzen, einen Fallback, i.d.R. Device-Code-Flow oder API-Schlüssel.

Drei immer wieder auftretende Sicherheitslücken#

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:

1. Vor dem Start generiert die CLI einen zufälligen code_verifier
2. Sie erzeugt einen code_challenge durch Hashen mit SHA-256
3. Die Challenge wird beim Authorisierungsschritt übertragen
4. Zum Token-Tausch sendet die CLI den code_verifier
5. Der Auth-Server prüft, ob Verifier und Challenge zusammenpassen

Ein 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.

3. API-Schlüssel und Personal Access Tokens#

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)

Wie es funktioniert#

1. Im Web-Dashboard des Dienstes anmelden
2. Zu Einstellungen → API-Schlüssel (oder Personal Access Tokens, Developer Tokens) navigieren
3. Neuen Key generieren, meist ein langer Zufallswert mit Prefix (z. B. sk_live_, ghp_, npm_)
4. Im Config-File (~/.config/stripe/config.toml, ~/.aws/credentials) oder einer Umgebungsvariable speichern

Die CLI liest ihn beim Start ein und schickt ihn typischerweise als Bearer-Token im Authorization-Header mitz.

Warum das trotz Risiken beliebt ist#

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 Risiken sind real#

• Leaks. API-Schlüssel landen in Commits, Logfiles, Fehlermeldungen, CI-Ausgaben. GitHub spürt jährlich über eine Million geleakte Tokens auf.
• Überprivilegiert. Die meisten API-Schlüssel geben sehr breite Rechte. Bei Leaks ist der Schaden groß.
• Kein MFA. API-Schlüssel umgehen den sorgfältig konfigurierten Multi-Faktor-Schutz.
• Schwer rotierbar. Jeder Dreh verlangt Updates überall – bei Teams ein Koordinationsproblem.

Moderne Verbesserung: Temporärer Token-Tausch#

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.

4. Client Credentials Flow#

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

Wie es funktioniert#

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.

Wann zu verwenden?#

Client Credentials Flow ist geeignet wenn:

• Ein Service oder Bot authentifizieren muss, nicht ein Mensch
• In CI/CD-Pipelines
• Für automatisierten, unbeaufsichtigten Zugriff
• Die "Nutzer" die Anwendung selbst ist

Nicht für Menschen verwenden! Keine MFA, kein SSO, keine interaktive Prüfung.

Was echte CLIs tatsächlich verwenden#

Hier eine korrigierte Übersicht laut aktueller Dokumentation und Quellcode. Viele Artikel liegen falsch, weil Tools ihre Defaults ändern.

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.

Token-Speicherung: Was ist gut, was ist schlecht#

Auth nützt nichts, wenn Tokens falsch gespeichert werden.

Der richtige Weg: Betriebssystem-Schlüsselbund#

Jedes größere OS hat einen eingebauten sicheren Credential-Speicher:

• macOS: Keychain (z.B. GitHub CLI, Claude Code)
• Windows: Credential Manager
• Linux: Secret Service API (GNOME Keyring, KDE Wallet)

Diese bieten Verschlüsselung, Zugriffskontrolle und ggf. Hardware-Security. Deine CLI muss keine eigene Kryptografie implementieren.

Fallback: Verschlüsselte Konfigdateien#

Wo kein Keychain verfügbar ist (Container, Minimal-Linux), verschlüsselte Config-Files mit restriktiven Berechtigungen:

Was vermeiden?#

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.

Token-Lebenszyklus-Management#

Access Tokens#

Kurzlebig halten. Eine Stunde ist Standard. Nach Ablauf sollte die CLI automatisch erneuern, nicht den Nutzer belästigen.

Refresh Tokens#

Langlebige Zugangsdaten zum Erneuern von Access-Tokens ohne erneute Authentifizierung. Wichtige Ziele für Angreifer, weil sie (Tage bis Monate) länger leben.

Refresh Token Rotation#

Moderne Auth-Systeme rotieren Refresh-Tokens bei jeder Nutzung:

1. CLI verwendet Refresh-Token zum Beantragen eines neuen Access-Tokens
2. Der Auth-Server gibt neuen Access- und ein neues Refresh-Token zurück
3. Das alte Refresh-Token wird sofort ungültig
4. CLI speichert beide neuen Tokens

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.

Häufige Fehler (mit Code)#

1. Callback-Server auf allen Interfaces binden#

Siehe oben – immer 127.0.0.1, niemals 0.0.0.0.

2. Tokens ins Log schreiben#

Passiert öfter, als zugegeben wird. Ein Debug-Log, ein Error-Handler, ein "verbose"-Modus ...

3. Zugangsdaten ins Container-Image einbacken#

Docker-Images sind keine Geheimnisspeicher. Jeder Layer ist extrahierbar.

4. Token-Ablauf nicht sauber behandeln#

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.

5. Prinzip der minimalen Rechte ignorieren#

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.

Das KI-Agenten-Dilemma#

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:

• Tokens mit minimalen, gescopeten Rechten für Agenten
• Möglichst kurzlebige Credentials (kurzzeitige Tokens statt API-Keys)
• Getrennte Agenten-Credentials, nicht persönliche Zugangsdaten
• API-Nutzung auf ungewöhnliche Muster überwachen

Entscheidungsrahmen#

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

FAQ#

Ist Device-Code-Flow sicher?#

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.

Sollten Tokens als Umgebungsvariablen gespeichert werden?#

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.

Unterschied API-Key vs. Personal Access Token?#

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.

Wie oft sollte ich Credentials rotieren?#

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.

Wie Auth in Docker-Containern handhaben?#

Drei Wege, nach Präferenz:

1. Device-Code-Flow für interaktiven Gebrauch (Browser auf anderem Gerät möglich)
2. Umgebungsvariablen zur Laufzeit (docker run -e API_KEY=${API_KEY}) im CI/CD
3. Credentials als Volume mounten (docker run -v ~/.config/tool:/root/.config/tool:ro) für lokale Entwicklung

Niemals Zugangsdaten ins Image einbacken. Niemals.

Und wie authentifiziert sich MCP (Model Context Protocol)?#

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.