Få CLI-autentisering rätt: den kompletta guiden till alla 4 metoder

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.

De fyra metoderna i korthet#

Innan vi går på djupet, här är en snabb jämförelse:

Varje metod har sina kompromisser. Här är vad du behöver veta om var och en.

1. OAuth device code flow (RFC 8628)#

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)

Så fungerar det#

1. Du kör cli login
2. CLI:t begär en enhetskod från autentiseringsservern och skickar sin client_id och begärda behörigheter
3. Servern returnerar tre saker: en device_code (intern identifierare), en user_code (koden du skriver in) och en verification_uri (var du ska gå in)
4. Din CLI visar koden och URL:en och börjar sedan poll:a autentiseringsservern var 5:e sekund eller mer
5. Du öppnar URL:en på valfri enhet (telefon, laptop, annan dator), skriver in koden och autentiserar hur du vill (lösenord, SSO, passkeys, MFA)
6. När du godkänner, returnerar nästa poll ett access token och ett refresh token
7. CLI:t sparar dessa och du är inne

Varför utvecklare gillar det#

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.

Säkerhetsfällan de flesta missar#

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.

Tekniska detaljer från RFC:n#

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.
• Om servern inte anger polling-interval måste klienten använda 5 sekunder.
• Om du får ett slow_down-fel, lägg till 5 sekunder till intervallet.
• Device codes bör vara engångskoder och löpa ut snabbt.
• Alla tokenutbyten måste ske via HTTPS.

2. Webbläsarbaserad OAuth (localhost-omdirigering)#

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)

Så fungerar det#

1. Du kör cli login
2. CLI:t startar en tillfällig HTTP-server på en slumpmässig lokal port (t.ex. http://127.0.0.1:8742)
3. Det öppnar din standardwebbläsare till autentiseringsleverantörens auktorisations-endpoint, med localhost-URL:en som redirect URI
4. Du autentiserar i webbläsaren (SSO, lösenord, passkeys, vad leverantören än stöder)
5. Autentiseringsleverantören omdirigerar webbläsaren till http://127.0.0.1:8742/callback?code=XXXX&state=YYYY
6. Den lokala servern fångar upp authorization code, byter den mot tokens via ett HTTPS-anrop
7. Webbläsaren visar en "Success! Du kan stänga denna flik"-sida
8. CLI:t sparar token och stänger servern

Användarupplevelsen är smidig. Inga koder att kopiera, inga URL:er att skriva in. Bara en flik som öppnas och stängs.

När det inte fungerar#

Detta fungerar bara när CLI:t kan öppna en webbläsare och binda till localhost. Det fungerar inte för:

• SSH-sessioner till fjärrservrar
• Docker-containrar (såvida du inte gör port-forwarding-knep)
• CI/CD pipelines
• Headless-servrar
• Vissa låsta företagsmiljöer

Därför har de flesta verktyg som använder browser OAuth också ett fallback, vanligtvis device code flow eller API-nycklar.

Tre säkerhetsfällor som ofta återkommer#

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:

1. Innan flödet startar genererar CLI:t en slumpmässig code_verifier (en stark sträng)
2. Skapar en code_challenge genom att hasha verifiern med SHA-256
3. Skickar challenge med första anropet
4. När koden byts mot token skickar CLI:t ursprungliga code_verifier
5. Auth-servern verifierar att verifier och challenge matchar

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

3. API-nycklar och personliga access tokens#

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)

Så fungerar det#

1. Logga in på tjänstens webbpanel
2. Gå till inställningar → API-nycklar (eller personliga access tokens, eller utvecklarnycklar)
3. Skapa en ny nyckel, oftast en lång slumpmässig sträng med prefix (t.ex. sk_live_, ghp_, npm_)
4. Spara den i en konfigfil (~/.config/stripe/config.toml, ~/.aws/credentials) eller som miljövariabel

CLI:t läser den vid start och skickar med i API-anrop, oftast som en Bearer-token i Authorization-headern.

Varför det fortfarande är populärt trots riskerna#

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.

Riskerna är verkliga#

• Läckor. API-nycklar hamnar i git-commits, loggfiler, felmeddelanden och CI-utskrifter. GitHub scannar efter exponerade tokens och rapporterar över en miljon läckta hemligheter per år.
• För breda rättigheter. De flesta API-nycklar ger bred access. Om de läcker blir spridningen av skadan stor.
• Ingen MFA. API-nycklar går förbi din välkonfigurerade multi-faktorautentisering.
• Svåra att rotera. Varje gång du byter nyckel måste du byta överallt där den används. Med team blir det en koordineringsutmaning.

Modern förbättring: engångstoken vid behov#

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.

4. Client credentials flow#

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

Så fungerar det#

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.

När det passar#

Använd client credentials när:

• En tjänst eller bot behöver autentisera, inte en människa
• Du har en CI/CD-pipeline
• Automatisk, obevakad access behövs
• "Användaren" är applikationen själv

Använd inte detta för människoinloggning. Det stöder inte MFA, SSO eller någon interaktiv verifiering.

Vad verkliga CLI-verktyg faktiskt använder#

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.

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.

Tokenlagring: vad man ska använda, vad man ska undvika#

Att göra autentiseringen rätt är meningslöst om du lagrar token fel.

Rätt sätt: OS keychains#

Varje större OS har ett inbyggt krypterat credentialstore:

• macOS: Keychain (används av GitHub CLI, Claude Code)
• Windows: Credential Manager
• Linux: Secret Service API (GNOME Keyring, KDE Wallet)

Dessa ger OS-nivåns kryptering, accesskontroll och hårdvarusäkerhetsintegration. Ditt CLI behöver inte egen kryptering.

Fallback: krypterade configfiler#

När keychain inte finns (containers, minimalistiska Linux-installationer), använd krypterade configfiler med restriktiva rättigheter:

Vad du ska undvika#

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.

Tokenlivscykelhantering#

Access tokens#

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#

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

Rotation av refresh-token#

Moderna authsystem roterar refresh-tokens varje gång de används:

1. CLI skickar refresh token för att få ny access token
2. Auth-servern returnerar en ny access token och en ny refresh token
3. Den gamla refresh token ogiltigförklaras genast
4. CLI:t sparar båda de nya token

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.

Vanliga fallgropar (med kod)#

1. Bindning av callback-server till alla gränssnitt#

Redan avhandlat ovan, men värt att upprepa: bind alltid till 127.0.0.1, aldrig till 0.0.0.0.

2. Loggning av tokens#

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.

3. Lagra credentials i container-images#

Docker-images är inte hemlighetsförvar. Varje lager kan extraheras.

4. Bristfälligt hanterande av utgånget token#

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.

5. Ignorera principen om minsta rättigheter#

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.

AI-agent-dimensionen#

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:

• Använd tokens med minsta möjliga rättigheter för agentarbetsflöden
• Föredra kortlivade credentials (tillfälliga tokens, inte långlivade API-nycklar)
• Använd dedikerade credentials för agenter, separerade från dina personliga
• Övervaka API-användningen efter oväntade mönster

Beslutsramverk#

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

FAQ#

Är device code flow säkert?#

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.

Ska jag lagra tokens i miljövariabler?#

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.

Vad är skillnaden på en API-nyckel och ett personligt access token?#

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.

Hur ofta bör jag rotera credentials?#

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.

Hur hanterar jag auth i Docker-containers?#

Tre alternativ, i prioritetsordning:

1. Device code flow för interaktivt bruk (fungerar för att webbläsaren kan vara på annan maskin)
2. Miljövariabler vid runtime (docker run -e API_KEY=${API_KEY}) för CI/CD
3. Volymmonterade credentials (docker run -v ~/.config/tool:/root/.config/tool:ro) för lokal utveckling

Lagra aldrig credentials i själva imagen. Aldrig.

Vad om MCP (Model Context Protocol) authentication?#

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.