Önemli olan 4 CLI kimlik doğrulama yöntemi, GitHub, AWS ve AI araçlarının bunları nasıl uyguladığı ve kaçınmanız gereken güvenlik hataları.
Her geliştirici CLI aracı, ilk komutu olarak login ile gelir. Ve her biri kimlik doğrulamayı farklı şekilde çözer.
GitHub sana bir kod gösterir ve doğrulaman için tarayıcını açar. AWS, PKCE tabanlı SSO için tarayıcıyı açar. Stripe, eşleştirme kodunu panelde onaylamanı ister. Yeni nesil AI araçları (Claude Code, OpenAI Codex CLI, Cursor) da her biri kendi yolunu seçti.
Bir CLI geliştiriyorsan, kimlik doğrulama ilk çözeceğin konulardan biridir. Yanlış yöntemi seçersen duyarsın: sinirlenen kullanıcılar, güvenlik denetimleri ya da her ikisi. Son zamanlarda CLI araçlarını programatik olarak çağıran AI kodlama ajanlarıyla beraber risk daha yüksek: artık sadece insanı değil, otonom bir süreci de yetkilendiriyorsun.
İşte önemli olan dört kimlik doğrulama yöntemi, en büyük araçlar bunları nasıl uyguluyor ve yapmaktan kaçınmak isteyeceğin hatalar.
Detaya inmeden, hızlı karşılaştırma:
| Yöntem | En iyi kullanım alanı | Güvenlik | Tarayıcı gerekli mi? |
|---|---|---|---|
| OAuth Device Code Flow | Arayüzsüz ortamlar, SSH | Yüksek | Hayır (aynı makinede değilse) |
| Tarayıcı tabanlı OAuth (localhost yönlendirme) | Lokal geliştirme | En yüksek | Evet |
| API Anahtarları / PAT'ler | Otomasyon, CI/CD, hızlı prototipleme | Orta | Hayır |
| Client Credentials (M2M) | Makineden makineye, servisler | Yüksek | Hayır |
Her birinin avantaj-dezavantajları var. Her biri için bilmen gerekenler:
Bu yöntemde CLI, sana ABCD-1234 gibi bir kod ve bir URL gösterir, sonra herhangi bir cihazdan o URL'yi açıp kodu girmeni ister.
Kullananlar: GitHub CLI (varsayılan), Azure CLI (--use-device-code ile), Vercel CLI (yakında varsayılan oldu), OpenAI Codex CLI (beta seçenek)
cli login komutunu çalıştırırsınclient_id ve gerekli izinleri gönderirdevice_code (iç kimlik), bir user_code (senin girdiğin kısa kod), ve bir verification_uri (gitmen gereken adres)En büyük özelliği: heryerde çalışması. Uzaktan bir sunucuya SSH ile girdin mi? Çalışır. Docker konteynerinde mi? Çalışır. Tarayıcısı olmayan bir bulut IDE’de mi? Çalışır! Tarayıcı ile CLI aynı makinede olmak zorunda değil.
Ayrıca tam kurumsal kimlik doğrulama yöntemlerinin (SAML, OIDC, MFA) tamamını da destekler. Bunun nedeni, tüm dessasmaranın tarayıcıda gerçekleşmesi, terminalde değil. CLI asla parolanı görmez.
Cihaz kodu akışının bir oltalama (phishing) problemi var. Saldırgan biri cihaz kodu isteği başlatıp geçerli bir kullanıcı kodu elde edip seni kandırabilir. Bu şekilde saldırganın oturumu onaylanır. Bu teorik bir risk değil. Güvenlik araştırmacıları bu saldırıyı AWS SSO cihaz kodu kimlik doğrulamasında belgeledi.
Bu o kadar büyük bir risk ki AWS varsayılanı değiştirdi. AWS CLI v2.22.0'dan itibaren, aws sso login için varsayılan yöntem cihaz kodu akışından PKCE tabanlı yetkilendirme kodu akışına geçti. Cihaz kodu hala --use-device-code ile kullanılabilir, ama artık varsayılan yol değil.
Bu arada, Microsoft’un kendi tenant’ı cihaz kodu akışını tamamen engellemeye başladı koşullu erişim politikaları ile — bu da onların bunu yüksek riskli bir kimlik doğrulama yöntemi olarak gördüğünün açık bir göstergesi.
Sonuçta ilginç bir ayrışma var: Vercel cihaz kodu akışını Eylül 2025’te varsayılan olarak benimsedi, AWS ise bundan uzaklaştı. Genel desen: Cihaz kodu akışı gerçekten tarayıcı açamayan ortamlar için harika, ama lokal bir tarayıcı açabiliyorsan PKCE daha güvenli tercih.
Kimlik sağlayıcı tarafında da talep artıyor. Logto kısa süre önce OAuth 2.0 Device Authorization Grant desteği ekledi, böylece native uygulamalar için cihaz akışını etkinleştirebilirsin. Bu, CLI geliştiriyorsan önemlidir. RFC 8628’i düzgün uygulamak (kod süresi, hız limiti, yoklama mantığı, doğrulama sayfasında oturum açma UX’i) çoğu zaman beklediğinden daha zordur, sağlayıcının bunu yönetmesi senin yalnızca doğru HTTP çağrılarını yapman anlamına gelir.
Birkaç önemli nokta:
expires_in değeri kimlik doğrulama sunucusu tarafından belirlenir. RFC 1800 saniye (30 dakika) örneği verir ama bu sabit değildir.interval’ı belirtmediyse, istemciler varsayılan olarak 5 saniye kullanmalı.slow_down hatası alınırsa, interval’e 5 saniye daha ekle.Bu yöntem geliştiricinin lokal makinesindeki CLI’lar için en yaygın yöntemdir. login çalıştırırsın, tarayıcı açılır, oturum açarsın ve tarayıcı, CLI’nın geçici olarak başlattığı lokal sunucuya geri yönlenir. Modern uygulamalar PKCE ("pixie" okunur) ekler, bu da süreci çok daha güvenli hale getirir.
Kullananlar: Claude Code, gcloud CLI, Terraform CLI, AWS CLI v2.22+ (varsayılan PKCE ile SSO’da)
cli login komutunu çalıştırırsın.http://127.0.0.1:8742)http://127.0.0.1:8742/callback?code=XXXX&state=YYYY adresine yönlendirirKullanıcı deneyimi çok akıcı: Kod kopyalamak yok, URL yazmak yok, sadece açılan bir sekme ve kapanır.
Bu sadece CLI bir tarayıcı açabildiğinde ve localhost’a bağlanabildiğinde çalışır. Şu ortamlar hariç:
Bu yüzden çoğu araç tarayıcı OAuth’u varsayılan alsa da genelde yedek olarak cihaz kodu akışı veya API anahtarları desteği de sunar.
Sorun 1: 0.0.0.0 yerine 127.0.0.1’e bağlanmak
En sık yapılan ve çok ciddi hata. Callback sunucun tüm arayüzleri dinlerse, aynı ağdaki herkes yetkilendirme kodunu yakalayabilir.
Birçok prod CLI’da bunu gördüm. Çünkü çoğu HTTP sunucu kütüphanesi varsayılan olarak 0.0.0.0 kullanır.
Sorun 2: State parametresi doğrulaması olmaması
state parametresi CSRF korumandır. Olmazsa, saldırgan CLI’nı kandırıp başka bir oturumdan gelen yetkilendirme kodunu kabul ettirebilir.
Sorun 3: PKCE kullanmamak
OAuth akışında PKCE (Proof Key for Code Exchange) yoksa, yetkilendirme kodu ele geçirilebilir ve yeniden oynatılabilir.
Normal yetkilendirme kodu akışında, eğer saldırgan authorization kodunu (ağdan veya yönlendirme URL'sinden okurken) ele geçirirse bunu token için kullanabilir. PKCE ise token değişiminin kimliği başlatan ile aynı istemciden geldiğini ispatlar ve kodu tamamlamak için gerekli olan code_verifier saldırganda olmaz.
PKCE’nin sürece ekledikleri:
code_verifier üretir (yüksek entropili dize)code_challenge oluşturur (SHA-256 ile)code_challenge ilk istekle gönderilircode_verifier’ı gönderirYetkilendirme kodunu ele geçiren saldırganın code_verifier’ı olmadığı için akışı tamamlayamaz.
Bu yüzden AWS CLI v2.22+ SSO’da PKCE’yi varsayılan yaptı ve cihaz kodu akışından uzaklaştı. CLI lokal tarayıcı açabiliyorsa, tarayıcı OAuth + PKCE cihaz kodu akışından daha güvenli ve aynı kullanıcı deneyimini sunar. Cihaz kodu akışı ise tarayıcı aynı makinede olamıyorsa (SSH, konteynerler, uzaktan geliştirme) hâlâ en iyi seçenektir ama lokal geliştirme için yaygın durum bu değildir.
En basit yöntem: Web panelinden token üretirsin, CLI yapılandırmasına ya da ortam değişkenine yapıştırırsın, işlem tamam.
Kullananlar: Stripe CLI (giriş seçeneği olarak), npm, pip, çoğu AI kodlama aracı (Claude Code - ANTHROPIC_API_KEY, OpenAI - OPENAI_API_KEY, Aider)
sk_live_, ghp_, npm_)~/.config/stripe/config.toml, ~/.aws/credentials) ya da ortam değişkenine eklersinCLI başlarken bunu okur ve API isteklerinde genellikle Authorization başlığında bir Bearer token olarak iletir.
Otomasyon için API anahtarları çok pratiktir. CI/CD’de, konteynerde, scriptte, cron’da çalışır. Ortam değişkenini okuyabilen her yerde. Tarayıcı gerekmez. İnteraktif adım gerekmez. Token yenileme gerekmez.
Özellikle AI ajan akışlarında, API anahtarı en kolay entegrasyon noktasıdır. Claude Code veya Cursor bir API çağıracaksa, ortam değişkeniyle API anahtarı en basit yoldur.
API anahtarı kullanıyorsan akıllıca olan, onu çalışma anında kısa ömürlü token ile değiştirmektir.
AWS, STS (Security Token Service) ile bunu başlattı. Uzun ömürlü kimlik bilgileriniz yalnızca 1 saat ömürlü geçici kimlik bilgisi almak için kullanılır. aws-vault gibi araçlar bu süreci tamamen otomatikleştirir.
API anahtarı ile başlasan bile bu modeli eklemeyi düşün. Bir anahtarı sızdırmakla oluşabilecek zarar penceresini "fark edilene kadar"dan "bir saat"e indirirsiniz.
Bu OAuth 2.0 akışı, makineden makineye (service-to-service) kimlik doğrulama için tasarlanmıştır: insansız servisler arası iletişim.
Kullanım alanı: CI/CD boru hatları, arka plan servisleri, otomatik araçlar
Servis doğrudan kendi client_id ve client_secret’ini kimlik sunucusuna gönderir ve kısa ömürlü bir erişim token’ı alır. Tarayıcı yok, insan müdahalesi yok, yönlendirme yok.
Şu durumlarda kullan:
İnsan kimlik doğrulaması için kullanılmaz. MFA, SSO veya interaktif doğrulamayı desteklemez.
Güncel dökümantasyon ve kaynak kod temel alınarak düzeltilmiş tablo. Yanlış bilgi çok çünkü araçlar sık sık varsayılanlarını değiştiriyor.
| CLI Aracı | Varsayılan kimlik doğrulama | Yedek seçenekler | Token depolama |
|---|---|---|---|
GitHub CLI (gh) | Cihaz kodu akışı (tarayıcı ile) | PAT (--with-token), ortam değişkeni (GH_TOKEN) | OS anahtarlık (yedek: düz dosya) |
| AWS CLI v2 | PKCE kod akışı (SSO) | Cihaz kodu (--use-device-code), kimlik dosyaları | ~/.aws/sso/cache/ |
Azure CLI (az) | WAM (Windows); tarayıcı kod akışı (Linux/macOS) | Cihaz kodu (--use-device-code) | ~/.azure/msal_token_cache.* |
| Vercel CLI | Cihaz kodu akışı (yeni varsayılan, Eyl 2025) | API tokenı (--token, ortam değişkeni) | ~/.local/share/com.vercel.cli/auth.json |
| Stripe CLI | Tarayıcı tabanlı eşleştirme akışı | API anahtarı (--interactive, --api-key, ortam değişkeni) | ~/.config/stripe/config.toml |
| gcloud CLI | Tarayıcı OAuth | --no-browser manuel akış | ~/.config/gcloud/ |
| Claude Code | Tarayıcı OAuth | API anahtarı (ortam değişkeni, apiKeyHelper) | OS anahtarlık / ~/.claude/.credentials.json |
| OpenAI Codex CLI | Tarayıcı OAuth | Cihaz kodu (beta), API anahtarı | ~/.codex/auth.json / OS anahtarlık |
| Terraform CLI | Tarayıcı OAuth | Token yapıştırma | ~/.terraform.d/credentials.tfrc.json |
Eğilimi görmek kolay: lokal geliştirmede varsayılan tarayıcı tabanlı OAuth, arayüzsüz ortamda yedek olarak cihaz kodu akışı, otomasyon için API anahtarları. PKCE, tarayıcı olduğu sürece en güvenli yol olarak yaygınlaşıyor.
Kimlik doğrulamayı doğru yapmak, tokenleri yanlış depolarsan hiçbir işe yaramaz.
Her büyük işletim sisteminde şifreli entegre kimlik bilgisi deposu vardır:
OS seviyesinde şifreleme, erişim kontrolü ve donanım güvenliği ile gelir. CLI’nın kendi şifrelemesini tasarlamasına gerek yoktur.
Anahtarlık yoksa (konteyner, minimal Linux kurulumları), erişim izinleri kısıtlı şifreli yapılandırma dosyası kullan:
Düz metin dosyalar. Kulağa bariz geliyor ama hâlâ birçok araç düz metin token dosyası kullanıyor. Aynı kullanıcıyla çalışan her proses, her yedekleme aracı ve makineye geçici erişimi olan herkes buna erişebilir.
Uzun vadeli ortam değişkeni kullanımı. Ortam değişkenleri süreç listelerinde görünür, genellikle hata raporlarında loglanır, alt süreçlere miras kalır. CI/CD için uygundur (platform yönetir) ama lokal geliştirme için risklidir.
Tarayıcı localStorage. CLI'da web bileşeni varsa, tokenleri localStorage'da tutma. XSS açığıyla her şey açığa çıkar.
Kısa ömürlü tut. Standart bir saatliktir. Token süresi bitince CLI şeffaf şekilde yenilemeli. Kullanıcı tekrar giriş yapmaya zorlanmamalı.
Yenileme tokenleri, tekrar kimlik doğrulaması olmadan yeni erişim tokeni almaya yarayan uzun ömürlü kimlik bilgileridir. Saldırganlar için yüksek değerli hedeflerdir (günlerce – aylarca yaşayabilirler).
Modern sistemler her kullanımda refresh tokeni döndürür:
Bir yenileme tokeni çalınırsa, bir sonraki kullanımda yasal kullanıcı altındaki yeni token çalışır; çalıntı tokeni kullanan saldırgan kalıcı erişime sahip olamaz, kullanıcı tekrar oturum açar ve saldırı bitsin.
Yukarıda da anlatıldı, tekrarlamakta fayda var: Daima 127.0.0.1’e, asla 0.0.0.0’a bağla.
Çoğumuzdan daha sık oluyor. Debug log, hata işleyici, verbose mod…
Docker imajları gizli bilgi deposu değildir. Her layer ayrıştırılabilir.
Token süresi ortada biterse sadece 401 hatası vermek yerine önce otomatik yenilemeyi dene, ancak refresh tokeni de geçersizse yeniden giriş iste.
admin:* izni isteme, sadece gerekli olanı (ör: repo:read) iste. Bu, hem OAuth izinleri hem de API anahtarlarının izinleri için geçerli.
Bir AI ajan CLI’nı kullanıyorsa, bu daha da önemli. Kod okuma için bir AI asistanına depo silme yetkisi vermek istemezsin.
2026 yılını 2023’ten farklı kılan: CLI'lar artık sadece insan komutları için değil. Claude Code, Codex, Cursor gibi AI kodlama ajanları CLI’ları programatik olarak çağırıyor. Bu yeni kimlik doğrulama sorunları doğuruyor:
Devirli izinler. Claude Code senin adına gh pr create çalıştırdığında senin GitHub kimlik bilgilerini kullanır. Ama bir AI ajanının seninle aynı yetkilere sahip olması gerekir mi? "En dar yetki" prensibi hayır diyor, ama çoğu araç bu imkanı desteklemez.
Kimlik bilgisi sızıntısı. API anahtarın ortam değişkenindeyse, AI ajanı alt süreç dâhil tüm süreçler görebilir. Claude Code gibi araçlar bu sorunu kısa ömürlü token üreten apiKeyHelper scriptleriyle çözüyor, ancak bu henüz yaygın değil.
Ajanlar için arayüzsüz kimlik doğrulama. Sandboxed ortamda çalışan bir AI ajanı tarayıcı açamaz. Cihaz kodu akışı burada işe yarar (insan başka cihazdan onaylar). Ama API anahtarı en çok kullanılan yoldur: sıfır etkileşimle çalışır.
Kayıt izleri. Bir AI ajan API çağrısı yaptığında audit logda sen yapmışsın gibi görünür. Şu anda "insan yaptı" ile "ajan insan adına yaptı" ayrımı yapmak için bir standart yok.
Bu alan hızlı evriliyor. Şu an yapabileceğin en iyi şey:
Kimlik doğrulama yöntemi mi seçiyorsun? Kısa hali:
"Kullanıcılarım kendi lokal makinelerinde geliştirici" → PKCE’li tarayıcı OAuth’u (en güvenli + akıcı UX)
"CLI’m SSH oturumu ve konteynerlerde çalışmalı" → Birincil: tarayıcı OAuth; yedek: cihaz kodu akışı
"CI/CD ortamında insan müdahalesi olmadan çalışacak" → Client credentials akışı veya izinli API anahtarları
"En hızlı şekilde implementasyon istiyorum" → API anahtarı (daha sonra token döngüsü ekle)
"Kurumsal müşterilerde SSO ve MFA lazım" → Herhangi OAuth akışı (cihaz kodu ya da tarayıcı); tüm kurumsal kimlik doğrulamayı destekler
"AI ajanları bu CLI'yı kullanacak" → API anahtarı (kolay ajan entegrasyonu) + tarayıcı OAuth’u (insan için), izinli ve kısa ömürlü tokenlerle
Çoğu saldırıya karşı güvenlidir, fakat bilinen bir phishing açığı vardır. Saldırgan bir kod oluşturup kullanıcıları bunu onaylatmaya kandırabilir. Bu yüzden AWS SSO girişinde varsayılanı PKCE yaptı. PKCE pratik değilse cihaz kodu akışı hala en iyi seçenektir. Sadece riskin farkında ol.
CI/CD için: evet, çünkü platform onları şifreli saklar, runtime’da aktarır. Lokal geliştirme için: hayır. OS anahtarlık kullan. Ortam değişkenleri süreç listelerinde görünür, loga girer veya alt süreçlere sızabilir.
Fonksiyonel olarak, çok az. İkisi de API isteklerini yetkilendiren uzun vadeli kimlik bilgileridir. Temelde API anahtarı genellikle proje/uygulama bazında, kişisel erişim tokeni kullanıcı hesabına özel olur. Bazı servislerde terimler birbirinin yerine de kullanılır.
Erişim tokenleri: en fazla her saatte bir (otomatik token yenileme sürecine bırakmalısın). Yenileme tokenleri: her kullanımda döndürülür (kimlik sunucusu başa çıkmalı). API anahtarları: en az 90 günde bir, veya şüphelenirsen hemen. Gerçekte çoğu takım ancak sızıntıdan sonra döndürür, bu çok geçtir.
Üç tercih, önem sırasına göre:
docker run -e API_KEY=${API_KEY}) — CI/CD içindocker run -v ~/.config/tool:/root/.config/tool:ro) — lokal geliştirme içinKimlik bilgisini imaja gömme. Asla.
MCP, AI ajanlarının harici araç ve servislerle bağlantı kurması için ortaya çıkan standarttır. Yeni bir boyut katar: ajan MCP sunucusuna bağlanmak için kimliğe ihtiyaç duyar; MCP de aşağıdaki API’lere erişmek için kimlik ister. Bu kısım hâlâ standartlaşmakta. Şimdilik çoğu MCP uygulaması yapılandırmada API anahtarı veya OAuth token geçer. Bunun çok hızlı evrilmesi bekleniyor.
CLI kimlik doğrulaması çok hızlı değişiyor. İki yıl önceki en iyi uygulamalar (cihaz kodu akışı varsayılan, düz metin kimlik dosyası) artık değişiyor. Bugün bir CLI’ya kimlik doğrulama ekliyorsan, insan için tarayıcı OAuth + PKCE, otomasyon için API anahtarıyla başla; AI ajanların ana kullanıcı olacağı geleceğe hazırlan.