Nämä 4 merkittävintä CLI-todennusmenetelmää, miten GitHub, AWS ja tekoälytyökalut toteuttavat ne, sekä tietoturva-ansat joita sinun kannattaa välttää.
Jokaisessa kehittäjä-CLI:ssa on login ensimmäisenä komentona. Ja jokainen ratkaisee todennuksen eri tavalla.
GitHub näyttää sinulle koodin ja avaa selaimen tunnistautumista varten. AWS avaa selaimen PKCE-pohjaista SSO:ta varten. Stripe pyytää vahvistamaan yhdistämiskoodin hallintapaneelissa. Uudemmat tekoälytyökalut (Claude Code, OpenAI Codex CLI, Cursor) ovat kaikki valinneet oman lähestymistapansa.
Jos rakennat CLI-työkalua, todennus on yksi ensimmäisistä asioista, jotka pitää ratkaista. Väärän menetelmän valitseminen johtaa nopeasti turhautuneisiin käyttäjiin, tietoturvatarkastuksiin tai molempiin. Ja kun tekoälyagentit käyttävät CLI-työkaluja ohjelmallisesti, panokset kasvavat: et enää todenna vain ihmistä, vaan annat mahdollisesti tunnisteita itsenäiselle prosessille.
Tässä ovat ne neljä autentikaatiomenetelmää, joilla oikeasti on väliä, miten suurimmat työkalut niitä toteuttavat, ja mitkä ovat yleisimmät sudenkuopat.
Ennen syvempää sukellusta, tässä nopea vertailu:
| Menetelmä | Parhaimmillaan | Tietoturva | Tarvitsee selaimen? |
|---|---|---|---|
| OAuth Device Code Flow | Päätelaitteettomat ympäristöt, SSH | Korkea | Ei (samalla koneella) |
| Selaimessa tapahtuva OAuth (localhost redirect) | Paikallisessa kehityksessä | Erittäin korkea | Kyllä |
| API-avaimet / PAT | Automaatio, CI/CD, nopea prototyyppaus | Kohtalainen | Ei |
| Client Credentials | Koneelta koneelle -palvelut | Korkea | Ei |
Jokaisella on omat kompromissinsa. Tässä keskeinen tieto jokaisesta.
Tässä CLI näyttää sinulle koodin, kuten ABCD-1234 ja URLin, ja pyytää sinua avaamaan kyseisen osoitteen millä tahansa laitteella ja syöttämään koodin.
Käytössä: GitHub CLI (oletuksena), Azure CLI (--use-device-code), Vercel CLI (uusi oletus), OpenAI Codex CLI (betavaihtoehtona)
cli loginclient_id:n ja pyydetyt scopes-arvotdevice_code (sisäinen tunniste), user_code (lyhyt koodi, jonka syötät) ja verification_uri (osoite, johon mennä)Suurin etu: tämä toimii missä vain. SSH-yhteys etäpalvelimelle? Toimii. Ajo Docker-kontissa? Toimii. Pilvi-IDE ilman paikallista selainta? Toimii. Selain ei tarvitse olla samalla koneella kuin CLI.
Tukee koko yrityksen autentikaatioarsenaalia (SAML, OIDC, MFA), koska kaikki tapahtuu selaimessa, ei terminaalissa. CLI ei koskaan näe salasanaasi.
Laitteiden koodivirta on altis phishingillä. Hyökkääjä voi aloittaa device code -pyynnön, saada laillisen user coden ja huijata sinut syöttämään sen, jolloin hyökkääjän sessio hyväksytään. Tämä ei ole teoreettista: tietoturvatutkijat ovat dokumentoineet tämän AWS SSO:n kanssa.
Tämän takia AWS vaihtoi oletusta. AWS CLI v2.22.0:sta alkaen aws sso login käyttää oletuksena PKCE-autentikaatiota laite-koodin sijaan. Device code on saatavilla vaihtoehtona, mutta se ei ole enää oletus.
Microsoftin oma tenantti on aloittanut device code -flown blokkaamisen kokonaan ehtokäytännöillä, mikä kertoo selkeästi, että se koetaan korkeaksi riskiksi.
Meillä on siis mielenkiintoinen jako: Vercel otti laitekoodin oletukseksi syyskuussa 2025, AWS luopui siitä. Näyttää siltä, että device code flow toimii parhaiten ympäristöissä, joissa selain ei aukea, mutta paikallisissa koneissa PKCE on turvallisempi.
Myös auth-palveluntarjoajilla kysyntä kasvaa. Logto julkaisi OAuth 2.0 Device Authorization Grant -tuensa versiossa v1.38.0 (open source) ja Logto Cloudissa, joten voit ottaa device flown käyttöön kaikissa natiiveissa sovelluksissa. Jos rakentaa CLI:tä, kannattaa hyödyntää valmista implementointia RFC 8628:sta: siinä on enemmän töitä kuin useimmat arvaavat (vanheneminen, rajoitukset, pollauslogiikka, käyttäjäkokemus todennussivulla) ja palveluntarjoaja hoitaa kaiken oikeiden HTTP-kutsujen lisäksi.
expires_in-arvon (kuinka pitkään laitekoodeja voi käyttää) määrää auth-palvelin. Esimerkin arvo on 1800 sekuntia (30 min), mutta ei ole tiukasti määritelty.interval-arvoa, asiakkaiden oletus pitää olla 5 sekuntia.slow_down-virheen, lisää 5 sekuntia pollaukseen.Tämä on yleisin menetelmä kehittäjän paikallisessa CLI:ssa. Kirjoitat login, selain aukeaa, tunnistaudut ja selain ohjataan takaisin CLI:n pystyttämälle paikalliselle palvelimelle satunnaiseen porttiin. Modernissa toteutuksessa on PKCE (lausutaan "pixie") mukana, mikä tekee hyökkäykset huomattavasti hankalammiksi.
Käytössä: Claude Code, gcloud CLI, Terraform CLI, AWS CLI v2.22+ (SSO:ssa PKCE oletuksena)
cli loginhttp://127.0.0.1:8742)http://127.0.0.1:8742/callback?code=XXXX&state=YYYYKäyttäjäkokemus on sujuva. Ei koodeja kopioitavaksi, ei urleja kirjoitettavaksi. Vain selainikkuna, joka avautuu ja sulkeutuu itsestään.
Tämä toimii vain, jos CLI pystyy avaamaan selaimen ja sitomaan localhost-porttiin. Poissuljettuja tapauksia:
Siksi monet työkalut, joiden oletus on selain-OAuth, tukevat fallbackina tyypillisesti device code –virtaa tai API-avaimia.
Virhe 1: Palvelimen bindaus osoitteeseen 0.0.0.0 eikä 127.0.0.1
Tämä on yleisin ja vaarallisin virhe. Jos callback-palvelin kuuntelee kaikkia osoitteita, kuka tahansa samassa verkossa voi siepata authorization coden.
Tämä on nähty tuotannossa. Monien HTTP-servicen kirjastojen oletus on 0.0.0.0.
Virhe 2: State-parametrin validoinnin puuttuminen
state-parametri suojaa CSRFiltä. Ilman sitä hyökkääjä voi huijata CLI:n hyväksymään authorization coden toisen session kautta.
Virhe 3: PKCE:n puuttuminen
Ilman PKCE:tä (Proof Key for Code Exchange) authorization code voidaan siepata ja käyttää uudelleen.
Normaalissa authorization code -flowssa, jos hyökkääjä saa koodin (verkkoliikenteestä tai redirect-URL:ista), hän voi vaihtaa sen tunnisteeksi. PKCE estää tämän, koska tokenin vaihton edellyttää, että sama CLI, joka aloitti pyynnön, viimeistelee myös vaihdon oikealla code_verifierilla.
PKCE:n lisäys flowhun:
code_verifierin (suuri entropia)code_challengenHyökkääjä ei saa code_verifieria, joten ei voi saada tunnisteita.
Tämän takia AWS CLI v2.22+ vaihtoi PKCE:n oletukseksi SSO:ssa. Kun CLI voi avata selaimen samalla koneella, selain-OAuth PKCE:llä on käytännössä kaikkein turvallisin ratkaisu – sama käyttökokemus, mutta vahvemmat tietoturvatakuut sekä ilman phishing-riskiä. Device code flow on yhä järkevä silloin, kun selain ei voi olla samalla koneella (SSH, kontit, etäkehitysympäristöt), mutta se ei ole tyypillisin paikallisen kehityksen tapaus.
Yksinkertaisin ratkaisu. Luo tunniste webissä, liitä se CLI:n asetuksiin tai ympäristömuuttujaan, valmis.
Käytössä: Stripe CLI (login-vaihtoehtona), npm, pip, useimmat tekoälytyökalut fallbackina (Claude Code ANTHROPIC_API_KEY:llä, OpenAI-työkalut OPENAI_API_KEY:llä, Aider)
sk_live_, ghp_, npm_ jne)~/.config/stripe/config.toml, ~/.aws/credentials) tai ympäristömuuttujaanCLI lukee sen käynnistettäessä ja lisää tunnisteen pyyntöihin, tyypillisesti Authorization-headerin Bearer-tokenina.
Automaatiolle API-avaimet ovat tehokkaita. Ne toimivat CI/CD:ssä, konteissa, scripteissä, cron-töissä. Missä tahansa, missä ympäristömuuttuja voidaan lukea. Selain ei tarvita, ei vuorovaikutteisia kehotteita, ei tokenin päivitysrumbaa.
Erityisesti tekoälyagentit hyödyntävät API-avaimia: Claude Code tai Cursor tarvitsee vain ympäristömuuttujan, helppo integraatio.
Fiksu tapa käyttää API-avaimia: vaihda ne lyhytikäisiksi tunnisteiksi ajon aikana.
AWS oli tässä edelläkävijä STS-palvelullaan. Pitkäikäisiä tunnuksia käytetään vain tilapäisten, tunnin kestävien kredentiaalien hakemiseen. Työkalut kuten aws-vault automatisoivat tämän.
Vaikka alkaisit API-avaimilla, harkitse tämän mallin lisäämistä. Näin mahdollinen vuotanut avain aiheuttaa vahinkoa korkeintaan tunnin ajan, eikä siihen asti, kunnes joku huomaa ja vaihtaa avaimen.
Tämä OAuth 2.0 -prosessi on suunniteltu koneiden keskinäiseen autentikaatioon: palvelu palvelun kanssa, ilman ihmisiä.
Käyttötapaukset: CI/CD, taustapalvelut, automaatiotyökalut
Palvelu lähettää client_id- ja client_secret -tunnisteen suoraan auth-palvelimelle ja saa lyhytikäisen access tokenin. Ei selainta, ei käyttäjän vuorovaikutusta, ei redirectia.
Käytä client credentials -flowta kun:
Älä käytä tätä ihmisen autentikaatioon. Ei tue MFA:ta, SSO:ta tai muuta vuorovaikutteista varmennusta.
Tässä ajantasainen yhteenveto dokumentaation ja lähdekoodin pohjalta. Monet artikkelit ovat vanhentuneita, koska työkalut muuttavat oletuksiaan usein.
| CLI-työkalu | Oletusautentikaatio | Fallback-vaihtoehdot | Tokenin tallennus |
|---|---|---|---|
GitHub CLI (gh) | Device code flow selaimessa | PAT (--with-token), ympäristömuuttuja (GH_TOKEN) | Käyttöjärjestelmän avainnippu (fallback: selväkielinen tiedosto) |
| AWS CLI v2 | PKCE auth code flow (SSO) | Device code (--use-device-code), credentials-tiedostot | ~/.aws/sso/cache/ |
Azure CLI (az) | WAM Windowsissa, selain-auth code flow Linux/macOS | Device code (--use-device-code) | ~/.azure/msal_token_cache.* |
| Vercel CLI | Device code flow (uusi oletus, syyskuu 2025) | API token (--token, ympäristömuuttuja) | ~/.local/share/com.vercel.cli/auth.json |
| Stripe CLI | Selaimessa paritusflow | API-avain (--interactive, --api-key, ymp. muuttuja) | ~/.config/stripe/config.toml |
| gcloud CLI | Selaimen OAuth | --no-browser manuaalinen flow | ~/.config/gcloud/ |
| Claude Code | Selain-OAuth | API-avain (ympäristömuuttuja, apiKeyHelper) | Käyttöjärjestelmän avainnippu / ~/.claude/.credentials.json |
| OpenAI Codex CLI | Selain-OAuth | Device code (beta), API-avain | ~/.codex/auth.json / OS keyring |
| Terraform CLI | Selain-OAuth | Token-liittämisliittymä | ~/.terraform.d/credentials.tfrc.json |
Trendi on selvä: selainpohjainen OAuth on oletus paikallisessa kehityksessä, device code flow päättömäksi fallbackiksi ja API-avaimet automaatioon. PKCE yleistyy kaikista turvallisimpana vaihtoehtona, kun selain on käytettävissä.
Täydellinen todennusratkaisu ei auta mitään, jos tallennat tunnisteet väärin.
Kaikissa suurimmissa käyttöjärjestelmissä on sisäänrakennettu salattu tunnistevarasto:
Nämä tarjoavat OS-tason salauksen, pääsynrajoitukset ja laitteistoturvan. CLI:n ei tarvitse toteuttaa omaa kryptografiaansa.
Jos avainnippua ei ole saatavilla (kontit, minimi-Linux-asennukset), käytä salattuja asetustiedostoja rajatuilla oikeuksilla:
Selväkieliset tiedostot. Tämä on ilmeistä, mutta moni työkalu tekee yhä näin. Selväkielinen tokenitiedosto on kaikkien prosessien, varmistusohjelmien ja tilapäistä pääsyä saaneiden luettavissa.
Ympäristömuuttujat pitkäaikaiseen tallennukseen. Ympäristömuuttujat näkyvät prosessilistauksissa, kirjautuvat crash-raporteissa ja periytyvät lapsiprosesseihin. Ne käyvät CI/CD:ssä (alusta hallinnoi niitä turvallisesti), mutta ovat riski paikalliseen kehitykseen.
Selaimen localStorage. Jos CLI:ssä on web-osio, älä tallenna tunnisteita localStorageen. Yksi XSS-vikava aiheuttaa koko salaisuuden vuodon.
Pidä nämä lyhytikäisinä. Usein yksi tunti on standardi. Kun access token vanhenee, CLI:n pitäisi päivittää se läpinäkyvästi. Käyttäjän ei tarvitse kirjautua uudelleen tavallisissa operaatioissa.
Refresh tokenit ovat pitkäikäiset tunnisteet, joilla saat uudet access tokenit ilman uutta kirjautumista. Ne ovat korkean riskin kohteita, koska niiden elinikä on pitkä.
Modernit auth-järjestelmät kierrättävät refresh tokenin joka käytöllä:
Tämä rajoittaa varastetun refresh tokenin aiheuttamaa tuhoa. Jos hyökkääjä käyttää tokenia, jonka CLI ehti käyttää, auth-palvelin tunnistaa uudelleenkäytön ja mitätöi koko token-perheen. Näin sekä hyökkääjän että käyttäjän nykyiset tokenit käyvät käyttökelvottomiksi ja kirjautuminen pitää uusia, mutta hyökkääjä ei saa pysyvää hyötyä.
Kuten yllä jo käsiteltiin: bindaa aina osoitteeseen 127.0.0.1, ei koskaan 0.0.0.0.
Tämä tapahtuu useammin kuin halutaan myöntää. Debug-logit, virheenkäsittelijät jotka tulostavat headerit, verbose-moodi joka näyttää kaiken.
Docker-images eivät ole salausvarastoja. Jokainen layer on palautettavissa.
Kun token vanhenee kesken operaation, älä vain kaadu 401-virheellä. Yritä uudistamista, ja varmista että vain jos refresh-token on myös vanhentunut, pyydä uudelleenkirjautumista.
Älä pyydä admin:*-scopea, kun tarvitset vain repo:read. Tämä pätee sekä OAuth-scopeihin että API-avainten oikeuksiin.
Kun tekoälyagentti käyttää CLI:tä, tämä on vielä tärkeämpää. Et todennäköisesti halua tekoälyavustajan voivan poistaa repoja vain siksi, että se lukee koodia.
Tässä mikä tekee vuodesta 2026 erilaisen 2023: CLI:t eivät ole enää vain ihmisille. Tekoälyohjaajat kuten Claude Code, Codex ja Cursor käyttävät CLI-työkaluja ohjelmallisesti. Tällöin syntyy uusia todennusongelmia:
Delemoidut oikeudet. Kun Claude Code suorittaa gh pr create puolestasi, se käyttää sinun GitHub-tunnuksiasi. Mutta pitäisikö agentilla olla samat oikeudet kuin ihmiskäyttäjällä? Vähimmän oikeuden periaate sanoo: ei, mutta lähes mikään työkalu ei rajoita agentin oikeuksia erikseen.
Tunnisteiden altistuminen. Jos API-avain on ympäristömuuttujassa, kaikki prosessit voivat lukea sen, mukaan lukien agentin aliprosessit. Claude Code on ratkaissut tämän apiKeyHelper-scripteillä, jotka generoivat tilapäisavaimia tarpeen mukaan, mutta tämä ei ole vielä laajasti käytössä.
Päätelaitteeton autentikaatio agenteille. Tekoälyagentti sandboxissa ei voi avata selainta. Device code flow toimii (käyttäjä hyväksyy toisella laitteella), mutta API-avaimet ovat yleisin ratkaisu, koska eivät vaadi vuorovaikutusta.
Audit-lokit. Kun agentti tekee API-kutsuja tunnuksillasi, audit-loki näyttää, että sinä teit kutsut. Ei ole vakiintunutta tapaa merkitä "tämän teki agentti ihmisen puolesta".
Tämä kenttä kehittyy jatkuvasti. Parhaat toimenpiteet juuri nyt:
Valitsetko todennusmenetelmää? Tässä lyhyt versio:
"Käyttäjäni ovat kehittäjiä omilla koneillaan" → Selainpohjainen OAuth PKCE:llä (paras tietoturva + hyvä käyttökokemus)
"CLI:n on toimittava SSH:ssa ja konteissa" → Device code fallbackina, selain-OAuth ensisijaisena
"Ajaa CI/CD:ssä ilman ihmistä" → Client credentials flow tai rajatut API-avaimet
"Haluan nopeimman mahdollisen toteutuksen" → API-avaimet (mutta lisää myöhemmin token-kierrätys)
"Yritysasiakkaat vaativat SSO:n ja MFA:n" → Mikä tahansa OAuth-flow (device code tai selain), tukee koko yritysautentikaation
"Tekoälyagentit käyttävät tätä CLI:tä" → Tue API-avaimia (helppo agentille) + selain-OAuth (ihmisille), käytä rajattuja oikeuksia ja lyhytikäisiä tunnisteita
Se on turvallinen useimpia hyökkäyksiä vastaan, mutta tunnettu phishing-aukkonsa vuoksi. Hyökkääjä voi generoida device coden ja huijata käyttäjän hyväksymään sen. Tämän takia AWS siirtyi PKCE:hen SSO-oletuksena. Päätelaitteettomissa ympäristöissä, joissa PKCE:tä ei voi käyttää, device code flow on silti paras vaihtoehto — huomio vain phishing-riski.
CI/CD:ssä kyllä, koska CI-alusta salaa ja syöttää ne ajonaikana. Paikallisessa kehityksessä ei: käytä käyttöjärjestelmän avainnippua. Ympäristömuuttujat näkyvät prosessilistauksissa ja voivat vuotaa lokiin tai lapsiprosessille.
Toiminnallisesti vain vähän. Molemmat ovat pitkäikäisiä tunnisteita API-pyyntöihin. Erona lähinnä hallinnollinen: API-avaimet liittyvät yleensä projektiin tai sovellukseen, käyttöoikeustunnisteet käyttäjätileihin. Osassa palveluita termejä käytetään ristiin.
Access tokenit: 1 tunnin tai alle välein (automaattisesti token refresh -flowlla). Refresh tokenit: kierrätä jokaisella käytöllä (palvelin huolehtii). API-avaimet: vähintään 90 päivän välein, välittömästi jos epäilet vuotoa. Käytännössä moni tiimi kierrättää API-avaimet vasta vahingon jälkeen — liian myöhään.
Kolme vaihtoehtoa, mieluisuusjärjestyksessä:
docker run -e API_KEY=${API_KEY}) CI/CD:ssädocker run -v ~/.config/tool:/root/.config/tool:ro) paikallisessa kehityksessäÄlä koskaan sisällytä tunnisteita kuvaan. Älä koskaan.
MCP on nouseva standardi tekoälyagenttien ja muiden työkalujen väliseen yhteyteen. Tämä tuo uuden kerroksen todennusta: agentti tarvitsee tunnisteet MCP-palvelimeen, joka tarvitsee tunnisteet alipalveluihin. Standardeja rakennetaan vielä. Nykyinen MCP-implementaatio käyttää usein API-avaimia tai OAuth-tunnisteita MCP-konfiguraation kautta. Tämä tulee kehittymään nopeasti.
CLI-todennus kehittyy nopeasti. Se, mikä oli best practice kaksi vuotta sitten (device code flow oletuksena, selväkielinen tiedosto), on jäämässä historiaan. Jos lisäät todennusta CLI:hin tänään, aloita selain-OAuth:lla + PKCE:llä ihmiskäyttäjille, API-avaimilla automaatioon, ja varaudu hetkeen jolloin tekoälyagentit ovat tärkeimmät käyttäjät.