De 4 CLI-autentiseringsmetoderna som spelar roll, hur GitHub, AWS och AI-verktyg implementerar dem samt de säkerhetsmisstag du vill undvika.
Varje utvecklar-CLI levereras med login som sitt första kommando. Och alla löser autentisering på olika sätt.
GitHub visar dig en kod och öppnar din webbläsare för att verifiera den. AWS öppnar en webbläsare för PKCE-baserad SSO. Stripe låter dig bekräfta en parningskod i instrumentpanelen. De nyare AI-verktygen (Claude Code, OpenAI Codex CLI, Cursor) har alla valt sina egna metoder.
Om du bygger ett CLI är autentisering en av de första sakerna du måste reda ut. Väljer du fel metod så kommer du höra om det: frustrerade användare, säkerhetsgranskningar, eller båda. Och med den senaste vågen av AI-kodagenter som anropar CLI-verktyg programmatiskt är insatserna högre: du autentiserar inte bara en människa längre. Du kan komma att lämna ut inloggningsuppgifter till en autonom process.
Här är de fyra autentiseringsmetoder som spelar roll, hur de största verktygen implementerar dem och de misstag du vill undvika.
Innan vi går på djupet, här är en snabb jämförelse:
| Metod | Bäst för | Säkerhet | Behövs webbläsare? |
|---|---|---|---|
| OAuth Device Code Flow | Headless-miljöer, SSH | Hög | Nej (på samma maskin) |
| Webbläsarbaserad OAuth (localhost-omdirigering) | Lokal utveckling | Högst | Ja |
| API-nycklar / PATs | Automatisering, CI/CD, prototyper | Medel | Nej |
| Client Credentials | Maskin-till-maskin, tjänster | Hög | Nej |
Varje metod har sina kompromisser. Här är vad du behöver veta om var och en.
Detta är den där din CLI visar en kod som ABCD-1234 och en URL, och ber dig att öppna den URL:en på valfri enhet och mata in koden.
Vem använder det: GitHub CLI (standard), Azure CLI (via --use-device-code), Vercel CLI (bytte nyligen till denna som standard), OpenAI Codex CLI (som beta-alternativ)
cli loginclient_id och begärda behörigheterdevice_code (intern identifierare), en user_code (koden du skriver in) och en verification_uri (var du ska gå in)Den stora fördelen: det fungerar överallt. SSH-session till en fjärrserver? Funkar. Kör inuti en Docker-container? Funkar. Cloud IDE utan lokal webbläsare? Funkar. Webbläsaren behöver inte vara på samma maskin som CLI:t.
Det stöder också hela spannet av företagsautentisering (SAML, OIDC, MFA) eftersom allt detta sker i webbläsaren, inte i terminalen. CLI:t ser aldrig ditt lösenord.
Device code flow har ett nätfiskeproblem. En angripare kan initiera en enhetskodsförfrågan, få en legitim användarkod och lura dig att mata in den, vilket ger angriparen behörighet. Det här är inte teoretiskt. Säkerhetsforskare har dokumenterat denna attack mot AWS SSO device code auth.
Detta är tillräckligt oroande för att AWS ändrade standarden. Från och med AWS CLI v2.22.0 är standarden för aws sso login PKCE-baserad authorization code flow istället för device code flow. Device code finns fortfarande via --use-device-code, men det är inte längre standardvägen.
Samtidigt har Microsofts egen tenant börjat blockera device code flow helt och hållet via conditional access-policies, vilket är en stark signal om att de ser det som en högriskmetod.
Så vi har en intressant splittring: Vercel införde device code flow som standard i september 2025, medan AWS gick bort från det. Mönstret verkar vara att device code flow är utmärkt i miljöer där du verkligen inte kan öppna en webbläsare, men om du kan öppna en lokalt är PKCE det säkrare valet.
På leverantörssidan växer efterfrågan tydligt. Logto har precis lanserat stöd för OAuth 2.0 Device Authorization Grant för native-appar i v1.38.0 (öppen källkod) och Logto Cloud, så du kan nu aktivera enhetsflöde som auktorisationsmetod för vilken native-applikation som helst. Det här är viktigt om du bygger ett CLI. Att implementera RFC 8628 korrekt (kodutgång, begränsning av anrop, polling-logik, sign-in-UX på verifieringssidan) är mer arbete än de flesta team tror, och om din autentiseringsleverantör hanterar det behöver du bara göra rätt HTTP-anrop.
Här är några saker att känna till från RFC 8628:
expires_in-värdet för device codes sätts av auth-servern. RFC ger 1800 sekunder (30 minuter) som exempel, men det är inget krav.interval måste klienten använda 5 sekunder.slow_down-fel, lägg till 5 sekunder till intervallet.Detta är den vanligaste metoden för CLIs på utvecklarens lokala maskin. Du kör login, webbläsaren öppnas, du autentiserar och webbläsaren skickas tillbaka till en lokal server som CLI:t startar tillfälligt. Moderna implementationer lägger till PKCE (uttalas "pixie") ovanpå, vilket gör flödet mycket svårare att utnyttja.
Vem använder det: Claude Code, gcloud CLI, Terraform CLI, AWS CLI v2.22+ (för SSO, med PKCE som standard)
cli loginhttp://127.0.0.1:8742)http://127.0.0.1:8742/callback?code=XXXX&state=YYYYAnvändarupplevelsen är smidig. Inga koder att kopiera, inga URL:er att skriva in. Bara en flik som öppnas och stängs.
Detta fungerar bara när CLI:t kan öppna en webbläsare och binda till localhost. Det fungerar inte för:
Därför har de flesta verktyg som använder browser OAuth också ett fallback, vanligtvis device code flow eller API-nycklar.
Fallgrop 1: Bindning till 0.0.0.0 istället för 127.0.0.1
Detta är det vanligaste misstaget och det är allvarligt. Om din callback-server lyssnar på alla gränssnitt kan vem som helst på samma nätverk fånga upp authorization code.
Jag har sett detta i produktions-CLI:er. Det är lätt att missa eftersom många HTTP-serverbibliotek använder 0.0.0.0 som standard.
Fallgrop 2: Saknad validering av state-parameter
state-parametern är ditt CSRF-skydd. Utan den kan en angripare lura ditt CLI att acceptera en authorization code från en skadlig session.
Fallgrop 3: Att inte använda PKCE
Om ditt OAuth-flöde inte använder PKCE (Proof Key for Code Exchange) kan authorization code fångas upp och återanvändas.
I ett vanligt authorization code flow kan en angripare som fångar authorization code (via nätverket, eller genom att läsa redirect-URL:en) byta ut den mot tokens. PKCE förhindrar detta genom att kräva bevis på att tokenutbytet initierats av samma klient som startade auktorisationen.
Detta lägger PKCE till i flödet:
code_verifier (en stark sträng)code_challenge genom att hasha verifiern med SHA-256code_verifierEn angripare som fångar authorization code har inte code_verifier, så hen kan inte slutföra bytet.
Detta är anledningen till att AWS CLI v2.22+ gjorde PKCE till standard för SSO och gick bort från device code flow. När CLI:t kan öppna en webbläsare på samma maskin är browser OAuth med PKCE helt enkelt bättre än device code flow — samma användarupplevelse, starkare säkerhetsgarantier, ingen risk för nätfiske. Device code flow är rätt val när webbläsaren inte kan vara på samma maskin (SSH, containers, fjärrutveckling), men det är inte det vanliga för lokal utveckling.
Det enklaste tillvägagångssättet. Du genererar en token i en webbpanel, klistrar in den i din CLI-konfiguration eller en miljövariabel, klart.
Vem använder det: Stripe CLI (som inloggningsval), npm, pip, de flesta AI-kodverktyg som fallback (Claude Code via ANTHROPIC_API_KEY, OpenAI via OPENAI_API_KEY, Aider)
sk_live_, ghp_, npm_)~/.config/stripe/config.toml, ~/.aws/credentials) eller som miljövariabelCLI:t läser den vid start och skickar med i API-anrop, oftast som en Bearer-token i Authorization-headern.
För automatisering är API-nycklar svårslagna. De funkar i CI/CD, containers, skript, cronjobb — överallt där man kan läsa en miljövariabel. Ingen webbläsare krävs. Inga interaktiva prompts. Ingen token-refresh-dans.
För AI-agent-arbetsflöden är API-nycklar den enklaste vägen. När Claude Code eller Cursor behöver anropa ett API är en miljövariabel med en API-nyckel den smidigaste integrationspunkten.
Den smarta lösningen med API-nycklar: byt dem mot kortlivade tokens vid runtime.
AWS var tidiga med detta via STS (Security Token Service). Dina långlivade inloggningsuppgifter används bara för att begära tillfälliga inloggningsuppgifter som löper ut på en timme. Verktyg som aws-vault automatiserar detta helt.
Även om du börjar med API-nycklar, fundera på att lägga till detta mönster. Det sänker skadefönstret från "tills någon upptäcker det" till "en timme" vid kompromettering.
Detta OAuth 2.0-flöde är designat för maskin-till-maskin-autentisering: tjänster som pratar med tjänster, ingen människa involverad.
Används i: CI/CD-pipelines, bakgrundstjänster, automatiserade verktyg
Tjänsten skickar sin client_id och client_secret direkt till autentiseringsservern och får ett kortlivat access token tillbaka. Ingen webbläsare, ingen användarinteraktion, ingen redirect.
Använd client credentials när:
Använd inte detta för människoinloggning. Det stöder inte MFA, SSO eller någon interaktiv verifiering.
Här är en korrigerad översikt baserat på aktuell dokumentation och källkod. Många artiklar missar detta eftersom verktygen hela tiden ändrar sina standardinställningar.
| CLI-verktyg | Standardauth | Fallback-alternativ | Token-lagring |
|---|---|---|---|
GitHub CLI (gh) | Device code flow via webbläsare | PAT (--with-token), miljövariabel (GH_TOKEN) | OS keychain (fallback: textfil) |
| AWS CLI v2 | PKCE-auth code flow (SSO) | Device code (--use-device-code), credential-filer | ~/.aws/sso/cache/ |
Azure CLI (az) | WAM i Windows; webbläsare-auth code flow på Linux/macOS | Device code (--use-device-code) | ~/.azure/msal_token_cache.* |
| Vercel CLI | Device code flow (ny standard, sep 2025) | API-token (--token, miljövariabel) | ~/.local/share/com.vercel.cli/auth.json |
| Stripe CLI | Webbläsarbaserat parningsflöde | API-nyckel (--interactive, --api-key eller miljövariabel) | ~/.config/stripe/config.toml |
| gcloud CLI | Webbläsar-OAuth | --no-browser manuellt flöde | ~/.config/gcloud/ |
| Claude Code | Webbläsar-OAuth | API-nyckel (miljövariabel, apiKeyHelper) | OS keychain / ~/.claude/.credentials.json |
| OpenAI Codex CLI | Webbläsar-OAuth | Device code (beta), API-nyckel | ~/.codex/auth.json / OS keyring |
| Terraform CLI | Webbläsar-OAuth | Token inklistrat | ~/.terraform.d/credentials.tfrc.json |
Trenden är tydlig: webbläsarbaserad OAuth är standard för lokal utveckling, med device code flow som fallback för headless-miljö, och API-nycklar för automatisering. PKCE vinner mark som det säkraste alternativet när webbläsare finns.
Att göra autentiseringen rätt är meningslöst om du lagrar token fel.
Varje större OS har ett inbyggt krypterat credentialstore:
Dessa ger OS-nivåns kryptering, accesskontroll och hårdvarusäkerhetsintegration. Ditt CLI behöver inte egen kryptering.
När keychain inte finns (containers, minimalistiska Linux-installationer), använd krypterade configfiler med restriktiva rättigheter:
Klartextfiler. Det borde vara självklart, men många verktyg gör fortfarande så. En klartext-tokenfil är tillgänglig för alla processer under din användare, alla backupverktyg, och alla som tillfälligt får access till din dator.
Miljövariabler för långtidslagring. Miljövariabler syns i processlistor, loggas ofta av crash-rapporterare och ärvs av barnprocesser. Det är okej för CI/CD (där CI-plattformen hanterar hemligheten), men riskabelt för lokal utveckling.
Webbläsarens localStorage. Om ditt CLI har en webbkomponent, lagra inte tokens i localStorage. En enda XSS-sårbarhet exponerar allt.
Låt dem vara kortlivade. En timme är standard. När access token löper ut bör CLI:t förnya det automatiskt. Användaren ska inte behöva logga in om för rutinåtgärder.
Refresh tokens är de långlivade credentials som låter dig få nya access tokens utan att logga in igen. De är högt värde för angripare eftersom de varar längre (dagar till månader).
Moderna authsystem roterar refresh-tokens varje gång de används:
Detta begränsar skadan om ett refresh token stjäls. Om en angripare försöker använda en refresh token som CLI:t redan använt upptäcker auth-servern återanvändningen och ogiltigförklarar hela tokengruppen. Både angriparens stulna token och användarens nuvarande token slutar fungera, vilket tvingar till ominloggning men hindrar angriparen från att bibehålla access.
Redan avhandlat ovan, men värt att upprepa: bind alltid till 127.0.0.1, aldrig till 0.0.0.0.
Detta händer oftare än någon vill erkänna. En debug-logg, en felhanterare som dumpar request headers, ett verbose-läge som skriver ut allt.
Docker-images är inte hemlighetsförvar. Varje lager kan extraheras.
När ett token löper ut mitt i en operation: krascha inte bara med fel 401. Försök att förnya, och be först om inloggning om också refresh token har gått ut.
Be inte om admin:* om du bara behöver repo:read. Detta gäller både OAuth scopes och rättigheter för API-nyckel.
När en AI-agent använder ditt CLI är detta ännu viktigare. Du vill troligen inte att en AI-assistent ska ha ta bort-repo-rättighet bara för att läsa kod.
Här är vad som gör 2026 annorlunda jämfört med 2023: CLI:er används inte bara av människor som skriver kommandon. AI-kodagenter som Claude Code, Codex och Cursor agent-läge anropar CLI-verktyg programmatiskt. Det skapar nya utmaningar för autentisering:
Delegerade rättigheter. När Claude Code kör gh pr create för din räkning används dina GitHub-inloggningar. Men ska en AI-agent ha samma rättigheter som du? Principen om minsta rättigheter säger nej, men de flesta verktyg saknar sätt att avgränsa agentens access.
Credential-exponering. Om din API-nyckel ligger i en miljövariabel kan varje process läsa den, inkl. AI-agentens subprocess. Verktyg som Claude Code har löst detta med apiKeyHelper-skript som genererar kortlivade tokens vid behov, men detta är inte universellt.
Headless auth för agenter. En AI-agent som kör i en sandlåda kan inte öppna webbläsare. Device code flow funkar här (människan godkänner på separat enhet), men API-nycklar är vanligare eftersom de inte kräver någon interaktion.
Loggningsspår. När en AI-agent gör API-anrop med dina uppgifter visas i loggarna att du gjort anropen. Det finns idag inget standardiserat sätt att skilja "människan gjorde detta" från "agenten gjorde detta för människan".
Detta är ett område i utveckling. Det bästa du kan göra nu:
Väljer du autentiseringsmetod? Här är snabbversionen:
"Mina användare är utvecklare på sina lokala datorer" → Webbläsar-OAuth med PKCE (bäst säkerhet + smidig UX)
"Mitt CLI måste fungera i SSH-sessioner och containers" → Device code flow som fallback, webbläsar-OAuth primärt
"Detta körs i CI/CD utan mänsklig inblandning" → Client credentials flow eller begränsade API-nycklar
"Jag behöver snabbast möjliga implementation" → API-nycklar (lägg till token-rotation senare)
"Företagskunder vill ha SSO och MFA" → Valfritt OAuth-flöde (device code eller webbläsare), som stöder alla företagskrav
"AI-agenter ska använda detta CLI" → Stöd API-nycklar (för enkel agentintegration) + webbläsar-OAuth (för människor), med rättighetsavgränsning och kortlivade tokens
Det är säkert mot de flesta attacker, men har en känd phishing-sårbarhet. En angripare kan generera en enhetskod och lura användare att godkänna den. Därför gick AWS över till PKCE som standard för SSO-login. I headless-miljöer där PKCE inte är praktiskt är device code flow ändå det bästa alternativet. Var bara medveten om phishing-risken.
För CI/CD: ja, för CI-plattformen krypterar dem vilande och matar in dem vid runtime. För lokal utveckling: nej. Använd OS keychain istället. Miljövariabler syns i processlistor och kan av misstag loggas eller ärvas till barnprocesser.
Funktionellt, mycket liten. Båda är långlivade credentials för att autentisera API-anrop. Distinktionen är organisatorisk: API-nycklar kopplas ofta till projekt eller applikation, personliga access tokens är bundna till ett användarkonto. Vissa tjänster använder termerna omväxlande.
Access tokens: varje timme eller oftare (sköts automatiskt via refresh flow). Refresh tokens: rotera vid varje användning (auth-servern bör göra detta). API-nycklar: minst var 90:e dag, eller omedelbart vid misstänkt läckage. I praktiken roterar de flesta team API-nycklar först efter en incident — vilket är för sent.
Tre alternativ, i prioritetsordning:
docker run -e API_KEY=${API_KEY}) för CI/CDdocker run -v ~/.config/tool:/root/.config/tool:ro) för lokal utvecklingLagra aldrig credentials i själva imagen. Aldrig.
MCP är standarden som växer fram för att AI-agenter ska kunna ansluta till externa verktyg och tjänster. Det tillför en ny auth-dimension: agenten behöver credentials för att prata med MCP-servern, som i sin tur behöver credentials för downstream-API:er. Standardisering pågår. För nu använder de flesta MCP-implementationer API-nycklar eller OAuth-token i MCP-konfigurationen. Räkna med snabba förändringar här.
CLI-autentisering förändras snabbt. Det som var best practice för två år sedan (device code flow som standard, klartextfiler) är redan på väg bort. Om du lägger till autentisering i ett CLI idag, börja med browser OAuth + PKCE för användare, API-nycklar för automatisering och planera för att AI-agenter en dag blir dina huvud-användare.