4 najważniejsze metody uwierzytelniania CLI, sposoby ich implementacji przez GitHub, AWS i narzędzia AI oraz błędy bezpieczeństwa, których warto unikać.
Każde deweloperskie CLI ma login jako pierwszą komendę. I każde rozwiązuje uwierzytelnianie inaczej.
GitHub pokazuje kod i otwiera przeglądarkę do potwierdzenia. AWS uruchamia przeglądarkę dla jednokrotnego logowania SSO opartego na PKCE. Stripe każe potwierdzić kod parujący na dashboardzie. Nowsze narzędzia AI (Claude Code, OpenAI Codex CLI, Cursor) wybrały jeszcze inne podejścia.
Jeśli tworzysz CLI, uwierzytelnianie to jedna z pierwszych rzeczy, które musisz rozgryźć. Wybierz złą metodę, a usłyszysz o tym: sfrustrowani użytkownicy, audyty bezpieczeństwa albo oba. Wraz z falą agentów kodujących AI, które wywołują narzędzia CLI programistycznie, stawka rośnie: nie uwierzytelniasz już tylko człowieka. Możesz oddać poświadczenia autonomicznemu procesowi.
Oto cztery metody uwierzytelniania, które się liczą, sposoby ich wdrażania w najpopularniejszych narzędziach oraz błędy, których warto unikać.
Zanim przejdziemy do szczegółów, krótkie porównanie:
| Metoda | Najlepsza dla | Bezpieczeństwo | Wymaga przeglądarki? |
|---|---|---|---|
| OAuth Device Code Flow | Środowiska bez interfejsu, SSH | Wysokie | Nie (na tej samej maszynie) |
| OAuth przez przeglądarkę (localhost redirect) | Lokalny development | Najwyższe | Tak |
| Klucze API / PAT | Automatyzacja, CI/CD, szybkie prototypowanie | Umiarkowane | Nie |
| Client Credentials | Maszyna-maszyna, usługi | Wysokie | Nie |
Każda metoda ma swoje wady i zalety. Oto najważniejsze informacje o każdej z nich.
To ta metoda, w której CLI wyświetla kod jak ABCD-1234 i adres URL, po czym każe ci otworzyć ten URL na dowolnym urządzeniu i wprowadzić kod.
Kto używa: GitHub CLI (domyślnie), Azure CLI (przez --use-device-code), Vercel CLI (niedawno zmieniło na domyślne), OpenAI Codex CLI (opcjonalnie, beta)
cli loginclient_id i wymagane scope'ydevice_code (wewnętrzny identyfikator), user_code (krótki kod do wpisania) oraz verification_uri (gdzie się udać)Największa zaleta: działa wszędzie. Sesja SSH na zdalnym serwerze? Działa. W kontenerze Docker? Działa. Cloud IDE bez przeglądarki lokalnej? Działa. Przeglądarka nie musi być na tej samej maszynie co CLI.
Obsługuje pełne uwierzytelnianie korporacyjne (SAML, OIDC, MFA), bo całość odbywa się w przeglądarce, nie w terminalu. CLI nigdy nie widzi twojego hasła.
Device code flow jest podatny na phishing. Atakujący może zainicjować żądanie kodu urządzenia, uzyskać prawidłowy kod użytkownika i oszukać cię, byś go wpisał, autoryzując w ten sposób sesję atakującego. To nie teoria. Badacze bezpieczeństwa udokumentowali taki atak przeciwko AWS SSO device code auth.
To tak poważny problem, że AWS zmieniło domyślne ustawienia. Od AWS CLI v2.22.0 domyślnie dla aws sso login stosowany jest już nie device code flow, tylko Authorization Code Flow z PKCE. Device code nadal jest dostępny przez --use-device-code, ale nie jest już domyślną ścieżką.
Jednocześnie sam Microsoft zaczął blokować device code flow przez polityki accessu warunkowego – to wyraźny sygnał wysokiego ryzyka tej metody.
Mamy ciekawy rozkład: Vercel wdrożyło device code flow jako domyślne we wrześniu 2025, AWS się wycofało. Wzorzec wydaje się jasny: device code flow jest świetny w środowiskach, gdzie naprawdę nie da się otworzyć przeglądarki, ale jeśli możesz ją otworzyć lokalnie, PKCE jest bezpieczniejsze.
Jeśli chodzi o dostawców autoryzacji – zapotrzebowanie rośnie. Logto właśnie wdrożyło wsparcie OAuth 2.0 Device Authorization Grant dla aplikacji natywnych w v1.38.0 (open source) oraz Logto Cloud, więc możesz już aktywować device flow jako opcję autoryzacji dla każdej aplikacji natywnej. To istotne, jeśli budujesz CLI. Poprawna implementacja RFC 8628 (wygasanie kodów, limitowanie żądań, logika odpytywania, UX logowania na stronie weryfikacji) to więcej pracy niż większość zespołów przewiduje, a jeśli obsługuje to dostawca autoryzacji, musisz tylko zrobić odpowiednie zapytania HTTP.
Kilka ważnych rzeczy z RFC 8628:
expires_in dla kodów urządzenia ustawia serwer autoryzacji. RFC podaje 1800 sekund (30 minut) jako przykład, ale to nie jest wymóg.slow_down dodaj 5 sekund do interwału.To najpopularniejsza metoda CLI uruchamianego na lokalnej maszynie dewelopera. Uruchamiasz login, otwiera się przeglądarka, uwierzytelniasz się, przeglądarka wraca na lokalny serwer, który CLI właśnie podniosło. Nowoczesne implementacje dodają PKCE (wym. "piksi"), co znacznie utrudnia ataki.
Kto używa: Claude Code, gcloud CLI, Terraform CLI, AWS CLI v2.22+ (dla SSO, PKCE domyślnie)
cli loginhttp://127.0.0.1:8742)http://127.0.0.1:8742/callback?code=XXXX&state=YYYYDoświadczenie dla użytkownika jest płynne. Żadnych kodów do przepisywania, żadnych linków do ręcznego otwierania. Po prostu otwiera się strona w przeglądarce.
Metoda działa tylko, gdy CLI może otworzyć przeglądarkę i nasłuchiwać na localhost. Odpada więc:
Dlatego większość narzędzi z domyślnym OAuth przez przeglądarkę wspiera fallback, zwykle device code flow albo klucze API.
Błąd 1: Nasłuchiwanie na 0.0.0.0 zamiast 127.0.0.1
Najczęstszy i bardzo poważny. Jeśli twój serwer callback nasłuchuje na wszystkich interfejsach, każdy w tej samej sieci może przechwycić kod autoryzacji.
Widziałem to w produkcyjnych CLI. Łatwo popełnić ten błąd, bo wiele bibliotek HTTP domyślnie nasłuchuje na 0.0.0.0.
Błąd 2: Brak walidacji parametru state
Parametr state to twoja ochrona przed CSRF. Bez niego atakujący może podsunąć CLI kod autoryzacyjny ze złośliwej sesji.
Błąd 3: Brak PKCE
Jeśli nie korzystasz z PKCE (Proof Key for Code Exchange), kod autoryzacyjny może zostać przechwycony i użyty ponownie.
W standardowym Authorization Code Flow, jeśli atakujący przechwyci kod autoryzacyjny (w sieci, odczytując URL), może wymienić go na tokeny. PKCE zapobiega temu – trzeba udowodnić, że wymiana tokenu jest inicjowana przez tego samego klienta, co zapytanie o autoryzację.
Co PKCE wnosi do flow:
code_verifier (ciąg wysokiej entropii)code_challenge przez hash SHA-256 verifieracode_verifierAtakujący, który przechwyci kod autoryzacji, nie posiada code_verifier, więc nie zakończy wymiany.
Dlatego AWS CLI v2.22+ domyślnie wymaga PKCE dla SSO, rezygnując z device code flow. Gdy CLI otwiera przeglądarkę na tej samej maszynie, OAuth przez przeglądarkę z PKCE zawsze wygrywa z device code flow — identyczne UX, silniejsze bezpieczeństwo, brak wektora phishingu. Device code flow jest dobrym wyborem tylko wtedy, gdy przeglądarka nie może być na tej samej maszynie (SSH, kontenery, środowiska zdalne), co nie jest normą dla lokalnego developmentu.
Najprostsze rozwiązanie. Generujesz token na dashbordzie webowym, wklejasz do configu CLI lub do zmiennej środowiskowej i gotowe.
Kto używa: Stripe CLI (jako opcja logowania), npm, pip, większość narzędzi AI jako fallback (Claude Code przez ANTHROPIC_API_KEY, narzędzia OpenAI przez OPENAI_API_KEY, Aider)
sk_live_, ghp_, npm_)~/.config/stripe/config.toml, ~/.aws/credentials) lub w zmiennej środowiskowejCLI odczytuje go przy starcie i dołącza do zapytań API jako token Bearer w nagłówku Authorization.
Do automatyzacji klucze API są niezastąpione. Działają w CI/CD, w kontenerach, w skryptach, w cronie. Wszędzie tam, gdzie można odczytać zmienną środowiskową. Bez przeglądarki, bez interakcji, bez odświeżania tokenu.
Dla agentowych workflow AI klucze API są najprostszą drogą. Gdy Claude Code czy Cursor musi wywołać API, zmienna środowiskowa z kluczem API to najłatwiejsza integracja.
Dobry ruch przy korzystaniu z kluczy API: wymieniaj je na tokeny krótkoterminowe w runtime.
AWS zapoczątkowało to z STS (Security Token Service). Twoje długowieczne poświadczenia służą tylko do żądania tymczasowych, wygasających po godzinie. Narzędzia typu aws-vault całkowicie to automatyzują.
Nawet zaczynając od kluczy API, warto dodać ten wzorzec. Ograniczasz wtedy okno szkód z "do wykrycia" do "1 godziny".
Ta metoda OAuth 2.0 jest zaprojektowana dla komunikacji maszyna-maszyna: serwisy rozmawiające ze sobą, bez udziału człowieka.
Wykorzystanie: Pipeline'y CI/CD, procesy w tle, narzędzia automatyczne
Serwis przesyła swój client_id i client_secret bezpośrednio do serwera autoryzacji i otrzymuje krótkoterminowy access token. Bez przeglądarki, bez interakcji, bez przekierowań.
Używaj client credentials gdy:
Nie używaj tego dla ludzi. Ta metoda nie wspiera MFA, SSO ani weryfikacji interaktywnej.
Oto poprawiony przegląd na bazie aktualnej dokumentacji i źródła. Wiele artykułów się myli, bo domyślne opcje często się zmieniają.
| Narzędzie CLI | Domyślne uwierzytelnienie | Opcje zapasowe | Miejsce przechowywania tokenów |
|---|---|---|---|
GitHub CLI (gh) | Device code flow przez przeglądarkę | PAT (--with-token), zmienna env (GH_TOKEN) | Keychain OS (zapas: plik tekstowy) |
| AWS CLI v2 | PKCE auth code flow (SSO) | Device code (--use-device-code), pliki credentials | ~/.aws/sso/cache/ |
Azure CLI (az) | WAM w Windows, w Linux/macOS browser auth code flow | Device code (--use-device-code) | ~/.azure/msal_token_cache.* |
| Vercel CLI | Device code flow (nowe domyślne, wrzesień 2025) | API token (--token, zmienna env) | ~/.local/share/com.vercel.cli/auth.json |
| Stripe CLI | Parowanie przez przeglądarkę | Klucz API (--interactive, --api-key, zmienna env) | ~/.config/stripe/config.toml |
| gcloud CLI | OAuth przez przeglądarkę | --no-browser manualne flow | ~/.config/gcloud/ |
| Claude Code | OAuth przez przeglądarkę | API key (zmienna env, apiKeyHelper) | Keychain OS / ~/.claude/.credentials.json |
| OpenAI Codex CLI | OAuth przez przeglądarkę | Device code (beta), API key | ~/.codex/auth.json / keyring OS |
| Terraform CLI | OAuth przez przeglądarkę | Wklejanie tokenu | ~/.terraform.d/credentials.tfrc.json |
Trend jest jasny: OAuth przez przeglądarkę dominuje dla lokalnego developmentu, device code flow jako zapas dla headless, a klucze API dla automatyzacji. PKCE szybko zyskuje jako najbezpieczniejsza opcja mając przeglądarkę.
Dobre uwierzytelnienie nic nie daje, jeśli źle przechowujesz tokeny.
Każdy większy system operacyjny ma zaszyfrowany wbudowany system przechowywania credentiali:
Zapewniają one szyfrowanie sprzętowe, kontrolę dostępu i integrację z zabezpieczeniami. Nie musisz implementować własnej kryptografii.
Gdy keychain jest niedostępny (kontenery, minimalny Linux), używaj szyfrowanych plików z restrykcyjnymi uprawnieniami:
Pliki tekstowe. To oczywiste, ale sporo narzędzi nadal tak robi. Taki plik jest dostępny dla każdego procesu użytkownika, dla każdego narzędzia backupu i wszystkich, którzy czasowo uzyskali dostęp do maszyny.
Zmienne środowiskowe do długotrwałego przechowywania. Zmienne env są widoczne w process listings, często logowane przez narzędzia crash reporting, dziedziczone przez podprocesy. Są OK w CI/CD (gdzie platforma zarządza sekretem), ale ryzykowne lokalnie.
localStorage przeglądarki. Jeśli twój CLI ma komponent webowy, nie przechowuj tam tokenów. Jedna luka XSS i wszystko wypłynie.
Trzymaj je krótkoterminowo. Godzina to standard. Gdy token wygasa, CLI powinno odświeżyć go przez refresh, bez wymagania ponownego logowania do zwykłych operacji.
Tokeny odświeżania to długowieczne poświadczenia pozwalające uzyskać nowe access tokeny bez ponownej autoryzacji. Są cennym celem atakujących – ich cykl życia to dni lub miesiące.
Nowoczesne systemy auth rotują refresh tokeny przy każdym użyciu:
To ogranicza szkody po kradzieży refresh tokenu. Jeśli atakujący spróbuje użyć tokenu odświeżania, który CLI już wykorzystało, serwer auth wykryje powtórne użycie i unieważni całą rodzinę tokenów. Zarówno token atakującego jak i twój przestają działać, co wymusza relogowanie i uniemożliwia utrzymanie dostępu przez atakującego.
Już omówione – zawsze nasłuchuj na 127.0.0.1, nigdy 0.0.0.0.
Dzieje się częściej niż ludzie przyznają. Log debug, error handler dumpujący headers, verbose tryb wypisujący wszystko.
Obrazy Dockera nie są skarbcami na sekrety. Każda warstwa jest do odczytu.
Gdy token wygasa w trakcie operacji, nie rzucaj 401 od razu. Spróbuj odświeżyć, a proś o relogowanie tylko gdy refresh token też nie działa.
Nie żądaj zakresu admin:* jeśli wystarczy repo:read. Dotyczy to zarówno scope'ów OAuth jak i uprawnień API key.
Gdy agent AI korzysta z twojego CLI, to szczególnie istotne. Nie chcesz, by asystent AI dostał uprawnienia kasowania repo tylko po to, by czytać kod.
Co odróżnia 2026 od 2023: CLI nie służą już tylko ludziom wpisującym komendy. Agenci kodujący AI typu Claude Code, Codex czy Cursor agent mode uruchamiają CLI programistycznie. To generuje nowe wyzwania dla auth:
Delegowane uprawnienia. Gdy Claude Code wykonuje gh pr create w twoim imieniu, używa twoich poświadczeń GitHub. Ale czy AI agent powinien mieć takie uprawnienia jak ty? Zasada minimalnych uprawnień mówi nie, ale większość narzędzi nie daje na razie mechanizmów ograniczania uprawnień agenta.
Ekspozycja poświadczeń. Jeśli trzymasz API key w zmiennej env, każdy proces może go odczytać – także podproces agenta AI. Narzędzia typu Claude Code rozwiązały to przez skrypty apiKeyHelper generujące krótkoterminowe tokeny na żądanie, ale to nie jest jeszcze standard.
Headless auth dla agentów. AI agent uruchomiony w sandboxie nie otworzy przeglądarki. Device code flow sprawdza się tu (człowiek autoryzuje na innym urządzeniu), ale klucze API są częstszym wyborem ze względu na brak interakcji.
Logi audytu. Operacje API wykonane przez agenta z twoimi poświadczeniami zapisują się w logu audytu jako twoje. Nie ma obecnie standardu rozróżniającego "człowiek to zrobił" od "agent zrobił to w imieniu człowieka".
To nadal się rozwija. Najlepsze co możesz robić:
Wybierasz metodę auth? Skrót:
"Moi użytkownicy to deweloperzy na ich lokalnych maszynach" → OAuth przez przeglądarkę z PKCE (najlepsze bezpieczeństwo + wygoda)
"CLI ma działać w SSH i w kontenerach" → Device code flow jako fallback, OAuth przez przeglądarkę jako priorytet
"To działa w CI/CD bez udziału człowieka" → Client credentials flow lub scope'owane klucze API
"Muszę wdrożyć najszybciej jak się da" → Klucze API (później rotacja tokenów)
"Klienci korporacyjni potrzebują SSO i MFA" → Dowolny flow OAuth (device code lub browser), wspiera pełen stack enterprise auth
"Agenci AI będą używać tego CLI" → Wsparcie kluczy API (dla prostoty agentów) + OAuth przez przeglądarkę (dla ludzi), scope'owane uprawnienia i krótkoterminowe tokeny
Jest bezpieczny przed większością ataków, ale ma znaną podatność na phishing. Atakujący może wygenerować device code i podsunąć go użytkownikom do autoryzacji. Dlatego AWS zmienił domyślną metodę na PKCE dla loginu SSO. W środowiskach headless, gdzie PKCE nie wchodzi w grę, device code to nadal najlepsza opcja — trzeba tylko liczyć się z ryzykiem phishingu.
Dla CI/CD: tak, bo platforma CI szyfruje je w spoczynku i wstrzykuje w runtime. Lokalnie: nie. Trzymaj tokeny w keychain OS. Zmienne env są widoczne w process listings oraz mogą trafić do logów czy podprocesów przez przypadek.
W praktyce niewielka. Obydwa to długoterminowe poświadczenia do autoryzacji zapytań API. Różnica jest zwykle organizacyjna: API key często przypisany jest do projektu lub aplikacji, PAT – do konta użytkownika. Niektóre usługi używają tych nazw zamiennie.
Access tokeny: co godzinę lub częściej (zwykle przez flow odświeżania, automatycznie). Refresh tokeny: rotacja przy każdym użyciu (powinna być obsługiwana przez serwer autoryzacji). Klucze API: minimum co 90 dni lub natychmiast po podejrzeniu wycieku. W praktyce większość zespołów rotuje klucze API dopiero po incydencie, co jest już za późno.
Trzy opcje, od najlepszej:
docker run -e API_KEY=${API_KEY}) w CI/CDdocker run -v ~/.config/tool:/root/.config/tool:ro) dla developmentu lokalnegoNigdy nie wrzucaj poświadczeń do obrazu. Nigdy.
MCP to powstający standard łączenia agentów AI z zewnętrznymi narzędziami i usługami. Wprowadza nowy wymiar auth: agent potrzebuje uwierzytelnienia do MCP servera, a ten do dalszych API. Standard dopiero się klaruje. Na razie większość implementacji MCP korzysta z kluczy API albo tokenów OAuth przekazywanych przez konfigurację MCP. Spodziewaj się szybkiej ewolucji w tej dziedzinie.
Auth CLI zmienia się szybko. To, co było dobrym standardem dwa lata temu (device code flow domyślnie, pliki tekstowe credentiali), już ustępuje nowym wzorcom. Jeśli dziś implementujesz auth w CLI, startuj z OAuth przez przeglądarkę + PKCE dla ludzi, kluczami API dla automatyzacji — i myśl o dniu, gdy to AI agenci będą twoimi głównymi użytkownikami.