CLI-todennuksen toteutus oikein: täydellinen opas kaikkiin 4 menetelmään

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.

Neljä menetelmää yhdellä silmäyksellä#

Ennen syvempää sukellusta, tässä nopea vertailu:

Jokaisella on omat kompromissinsa. Tässä keskeinen tieto jokaisesta.

1. OAuth device code flow (RFC 8628)#

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)

Miten se toimii#

1. Suoritat cli login
2. CLI pyytää laitesalasanan autentikaatiopalvelimelta, lähettäen oman client_id:n ja pyydetyt scopes-arvot
3. Palvelin palauttaa kolme asiaa: device_code (sisäinen tunniste), user_code (lyhyt koodi, jonka syötät) ja verification_uri (osoite, johon mennä)
4. CLI näyttää koodin ja URL:n, ja aloittaa palvelimen pollauksen 5+ sekunnin välein
5. Avaa URL millä tahansa laitteella (puhelin, läppäri, eri tietokone), syötä koodi ja todenna haluamallasi tavalla (salasana, SSO, passkeys, MFA)
6. Hyväksynnän jälkeen seuraava pollaus palauttaa access tokenin ja refresh tokenin
7. CLI tallentaa tunnisteet ja olet kirjautunut sisään

Miksi kehittäjät pitävät tästä#

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.

Usein unohdettu tietoturvaongelma#

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.

RFC:n teknisiä yksityiskohtia#

• 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.
• Jos palvelin ei palauta pollaus interval-arvoa, asiakkaiden oletus pitää olla 5 sekuntia.
• Jos saat slow_down-virheen, lisää 5 sekuntia pollaukseen.
• Device code pitäisi olla yksikäyttöinen ja vanheta nopeasti.
• Kaikkien token-vaihto-operaatioiden tulee tapahtua HTTPS:llä.

2. Selaimessa tapahtuva OAuth (localhost-redirect)#

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)

Miten se toimii#

1. Suoritat cli login
2. CLI käynnistää tilapäisen HTTP-palvelimen satunnaiselle paikalliselle portille (esim. http://127.0.0.1:8742)
3. Avaa tiedot auth-palvelulle selainikkunaan, käyttäen localhost-osoitetta redirect-uri:na
4. Tunnistaudut selaimessa (SSO, salasana, passkeys, mitä palvelu tukee)
5. Auth-palvelin ohjaa selaimen osoitteeseen kuten http://127.0.0.1:8742/callback?code=XXXX&state=YYYY
6. Paikallinen palvelin vastaanottaa authorization coden ja vaihtaa sen tunnisteisiin HTTPS:llä
7. Selain näyttää onnistumissivun ja välilehden voi sulkea
8. CLI tallentaa tokenit ja sammuttaa palvelimen

Käyttäjäkokemus on sujuva. Ei koodeja kopioitavaksi, ei urleja kirjoitettavaksi. Vain selainikkuna, joka avautuu ja sulkeutuu itsestään.

Milloin ratkaisu ei toimi#

Tämä toimii vain, jos CLI pystyy avaamaan selaimen ja sitomaan localhost-porttiin. Poissuljettuja tapauksia:

• SSH-etäyhteydet
• Docker-kontit (ilman porttiohjauksen taiteiluja)
• CI/CD-pipeline
• Päätelaitteettomat palvelimet
• Joissain rajoitetuissa yritysympäristöissä

Siksi monet työkalut, joiden oletus on selain-OAuth, tukevat fallbackina tyypillisesti device code –virtaa tai API-avaimia.

Kolme toistuvaa tietoturvan sudenkuoppaa#

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:

1. CLI generoi satunnaisen code_verifierin (suuri entropia)
2. Luo siitä hashilla SHA-256 code_challengen
3. Lähettää haasteen alkuperäisessä pyynnössä
4. Vaihtaessaan codea tunnisteeseen CLI lähettää alkuperäisen code_verifierin
5. Auth-palvelin tarkistaa että verifier ja challenge mätsäävät

Hyö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.

3. API-avaimet ja henkilökohtaiset käyttöoikeustunnisteet (PAT)#

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)

Miten se toimii#

1. Kirjaudu palvelun web-hallintapaneeliin
2. Mene asetuksiin → API-avaimet (tai PAT, developer tokens...)
3. Luo uusi avain. Yleensä pitkä satunnainen merkkijono, prefiksillä (sk_live_, ghp_, npm_ jne)
4. Talleta se konfiguraatiotiedostoon (~/.config/stripe/config.toml, ~/.aws/credentials) tai ympäristömuuttujaan

CLI lukee sen käynnistettäessä ja lisää tunnisteen pyyntöihin, tyypillisesti Authorization-headerin Bearer-tokenina.

Miksi tämä on edelleen suosittu riskeistä huolimatta#

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.

Riskit ovat todellisia#

• Vuodot. API-avaimet päätyvät gitiin, lokeihin, virheilmoituksiin ja CI-tulosteisiin. GitHub skannaa ja raportoi yli miljoona vuotanutta salaisuutta vuodessa.
• Liian laajat oikeudet. Useimmat API-avaimet sallivat laajat toiminnot. Jos vuotavat, vahinko on suuri.
• Ei monivaiheista tunnistusta. API-avaimet ohittavat kaikki MFS- ja muut vahvistukset.
• Vaikea kierrättää. Joka kerta kun kierrätät avaimen, pitää päivittää se joka paikkaan. Ryhmissä tämä on ongelma.

Moderni parannus: tilapäinen tunnisteenvaihto#

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.

4. Client credentials flow#

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

Miten se toimii#

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.

Missä tätä käytetään#

Käytä client credentials -flowta kun:

• Palvelu tai botti tarvitsee tunnistautua ihmisen sijaan
• Olet CI/CD-pipelinessä
• Tarvitaan automaattinen, vuorovaikutteeton pääsy
• "Käyttäjä" on itse sovellus

Älä käytä tätä ihmisen autentikaatioon. Ei tue MFA:ta, SSO:ta tai muuta vuorovaikutteista varmennusta.

Miten oikeat CLI:t toteuttavat todennuksen#

Tässä ajantasainen yhteenveto dokumentaation ja lähdekoodin pohjalta. Monet artikkelit ovat vanhentuneita, koska työkalut muuttavat oletuksiaan usein.

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

Tunnisteiden tallennus: mitä käyttää, mitä välttää#

Täydellinen todennusratkaisu ei auta mitään, jos tallennat tunnisteet väärin.

Oikein: käyttöjärjestelmän avainniput#

Kaikissa suurimmissa käyttöjärjestelmissä on sisäänrakennettu salattu tunnistevarasto:

• macOS: Keychain (GitHub CLI, Claude Code käyttävät tätä)
• Windows: Credential Manager
• Linux: Secret Service API (GNOME Keyring, KDE Wallet)

Nämä tarjoavat OS-tason salauksen, pääsynrajoitukset ja laitteistoturvan. CLI:n ei tarvitse toteuttaa omaa kryptografiaansa.

Fallback: salatut konfiguraatiotiedostot#

Jos avainnippua ei ole saatavilla (kontit, minimi-Linux-asennukset), käytä salattuja asetustiedostoja rajatuilla oikeuksilla:

Mitä välttää#

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.

Tunnisteiden elinkaarihallinta#

Access-tunnisteet#

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-tunnisteet#

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

Refresh tokenin kierrätys#

Modernit auth-järjestelmät kierrättävät refresh tokenin joka käytöllä:

1. CLI lähettää refresh tokenin saadakseen uuden access tokenin
2. Auth-palvelin palauttaa uuden access tokenin ja uuden refresh tokenin
3. Vanhat refresh tokenit mitätöidään välittömästi
4. CLI tallentaa molemmat uudet tokenit

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

Yleiset sudenkuopat (koodiesimerkein)#

1. Callback-palvelimen bindaus kaikkiin osoitteisiin#

Kuten yllä jo käsiteltiin: bindaa aina osoitteeseen 127.0.0.1, ei koskaan 0.0.0.0.

2. Tunnisteiden loggaaminen#

Tämä tapahtuu useammin kuin halutaan myöntää. Debug-logit, virheenkäsittelijät jotka tulostavat headerit, verbose-moodi joka näyttää kaiken.

3. Tunnisteiden sisällyttäminen container-kuviin#

Docker-images eivät ole salausvarastoja. Jokainen layer on palautettavissa.

4. Tokenin vanhentumisen käsittelyn puute#

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.

5. Vähimmän oikeuden periaatteen unohtaminen#

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

Tekoälyagenttien erityishaasteet#

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:

• Käytä suppeasti rajattuja tunnisteita agenttien workflowssa
• Suosi lyhytikäisiä tunnisteita (tilapäis-tunnukset, ei pitkäikäisiä avaimia)
• Käytä agentille omaa tunnistetta, erillään henkilökohtaisesta
• Seuraa API-käyttöä yllättävien mallien varalta

Päätösrunko#

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

Usein kysyttyä#

Onko device code flow turvallinen?#

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.

Pitäisikö tallentaa tunnisteet ympäristömuuttujiin?#

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.

Mikä ero on API-avaimella ja henkilökohtaisella käyttöoikeustunnisteella?#

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.

Kuinka usein kannattaa kierrättää tunnisteet?#

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.

Miten todennus kannattaa hoitaa Docker-konteissa?#

Kolme vaihtoehtoa, mieluisuusjärjestyksessä:

1. Device code flow vuorovaikutteiseen käyttöön (toimii koska selain voi olla toisella laitteella)
2. Ympäristömuuttujat ajonaikana (docker run -e API_KEY=${API_KEY}) CI/CD:ssä
3. Volume-mountatut tunnisteet (docker run -v ~/.config/tool:/root/.config/tool:ro) paikallisessa kehityksessä

Älä koskaan sisällytä tunnisteita kuvaan. Älä koskaan.

Entä MCP (Model Context Protocol) -autentikaatio?#

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.