Kimlik Doğrulama Token’ları Neden Asla “Veri Sözleşmesi” Değildir?
Giriş: Tokenlar Güvenliğin Kapıcısı mı, Veri Ambarı mı?
Şimdi dürüst olalım; Azure ya da başka bir bulutta uygulama geliştirirken eliniz token’ın içine gitmedi mi hiç? Kimlik doğrulama token’ını açıp “Aaa, kullanıcı adı burada yazıyor… Rolü de şurada!” diye kendinize veri avladığınız o anı unutun. Ben mesela, 2017’de bir müşteri portalına entegre olurken JWT’yi çat diye decode edip departman bilgisini çıkarmıştım. İlk bakışta muazzam pratik! Ama gerçek bambaşka. Şunu net söyleyeyim: Authentication token dediğiniz şey, uygulamanın “veritabanı” değildir (ciddiyim). Onun tek derdi var — istekte bulunan gerçekten bu adam mı ve buna yetkisi var mı? Hepsi bu.
Doğrusu, Peki sahada neler oluyor? İşte orası biraz karanlık… Halen onlarca ekip token içeriğini öyle sabit sanıyor ki sanki önlerinde 10 yıllık imzalı sözleşme var! Bu yüzden oturdum bunları dökeyim dedim – (ben de ilk duyduğumda şaşırmıştım). Yakında özellikle Azure DevOps cephesinde işler fena hâlde değişecek gibi dürüyor.
Token İçeriğine Neden Asla Güvenmemelisiniz?
Token = Post-it Kağıdı, API = Tapu Senedi
Kafanda banka kartını canlandır; üstünde işim soyisim var. Bakiyeni öğrenmek için karta değil bankanın mobil uygulamasına giriyorsun değil mi? Kimlik doğrulama token’ı da tam olarak böyle çalışır — geçici pasaport gibi bir şey. Belki üzerinde üç beş not taşıyor ama asla sırtınızı ona dayayamazsınız.
Bunu zor yoldan öğrenmiş biri olarak anlatayım: 2021’de büyük bir finans firmasının özel dashboard’una takviye yaparken kullanıcı ID’si direkt token’dan alınıyordu. Sonra Microsoft küçük bir güncelleme yaptı ve ilgili claim’in ismini değiştirdi… Ne loglarda ipucu kaldı ne release notlarında açıklama – ekranda sadece patlayan hata mesajlarıyla geçen iki gün! Uzun lafın kısası: Kodunuz token’a bağımlıyken mutlu son hayal etmeyin.
Token’ın içindeki hiçbir bilgiye uzun vadeli garanti verilemez. Büyük firmalar genelde istedikleri zaman içerikte oynama hakkını ellerinde tutar.
Neden Böyle Olmak Zorunda?
- Büyük ürünler (Microsoft örneği) resmî dokümantasyonda “şu claim hep aynı formatta gelir” demez.
- Bazen güvenlik gerekçesiyle yeni alan eklenir veya eski kaldırılır – hızla değişir yanı.
- Mimarı büyüyüp gelişince arka planda formatlar tamamen evrim geçiriyor, eskiler rafa kalkabiliyor.
Tüm bunlara kulak tıkayıp illâ ki gidip doğrudan token’dan veri çekerseniz… geçmiş olsun, kodda saati kurulmuş bomba sizi bekliyor!
Kişisel Deneyim: Token’a Güvenmekten Nasıl Caydım?
Şöyle ki, Biraz daha açayım; 2019’da Logosoft’taki bir müşteri projesinde, onboarding sürecinde departman bilgisi token’dan çekiliyordu. Birkaç ay sonra bir güncelleme sonrası claim kayboldu ve ekibin onboarding API’si aniden bozuldu. O sabah toplantıda, neden “departman” yok diye tartışırken elimizde olan tek şey token’dı! Sonuç: birkaç gün patch ve test… O andan itibaren her ekibe “Token’ın içindeki veri, sabit veri değildir” diye baş baş bağırıyorum. Bu yaşanmış tecrübe sonsuza kadar aklımda kaldı.
Kimlik doğrulama token’ları (ör. JWT) kullanıcıyı doğrulamak için tasarlanmıştır; “veri sözleşmesi” gibi içeriğine kalıcı şekilde güvenmek doğru değildir. İç claim’ler değişebilir ve uygulamalar beklenmedik şekilde bozulabilir.
| Özellik | Kimlik Doğrulama Token’ları |
|---|---|
| Amaç | İstek sahibinin kim olduğunu ve yetkisini kontrol etmek |
| Token içeriği | Geçici/operasyonel claim’ler; sabit veri garantisi yok |
| Risk | Claim adı/formatı değişirse kod ve entegrasyonlar kırılır |
| Doğru yaklaşım | Token’ı doğrulama için kullan, kalıcı veri için API/DB gibi kaynaklara dayan |
Not: “Token’dan kullanıcı/rol/veri çekeyim” alışkanlığı kısa vadede pratik görünse de sürdürmesi risklidir.
Büyük Değişiklik Yolda: Artık Tokenlar OPAK Hâle Geliyor!
Sürpriz Yaz Sıcağı – Şifrelenmiş Token Çağı Başlıyor
Bak şimdi sıkı dur; Azure DevOps ekibi yaz aylarına doğru kritik bir hamle yapacak. Kısaca şu olacak: Authentication token’larının içi artık daha sıkı şifrelenecek. Dışarıdan erişip okumak neredeyse imkansız hâle gelecek. Üstelik bazı projelerde beklenen tarihten bile erken geçiş başlatılıyor diyenler var…
Dikkat! Eğer hâlâ aşağıdaki yollarla iş görmeye çalışıyorsanız:
decode(token)ile payload’u açıp JSON’dan bilgi devşiriyorsanız- Bir tane claim’i doğrudan iş mantığında input gibi kullanıyorsanız
Kötü haber vereyim; bu kod artık çöpe gidecek arkadaşlar (ciddiyim). Çünkü artık o bilgiler gözükmeyecek — her şey simsiyah kutuya dönüşüyor resmen.
Yeni dönemde bu tavır iyice sertleşecek.
Açıkçası… İlk Morali Bozan Adam Ben Oldum!
Açık konuşayım, Ankara’da Logosoft projesinde ilk büyük göçlerden birinde basitçe işi hızlandırmak için departmentId’yi hızlıca tokendan çektik (2019). Başta süper görünüyordu fakat kısa süre sonra fark ettik ki bazen o claim gelmiyor! Sonrası klasik uğraşı — neden hata verdi bulmaya çalışıyoruz… O günden beri REST API dışında veri kaynağı tanımıyorum kendime – size de aynısını öneririm valla!
Token Opaklığı: Pratikte Neyi Değiştiriyor?
2018’de bir SaaS projesinde, frontend ekibi customerId’yi tokendan çekiyordu. Opak token’a geçişle birlikte, api endpoint’e ek bir çağrı eklemek zorunda kaldık. Başta ekibe “ya neden uğraştırıyorsunuz” dediler, ama 3 ay sonra yeni claim yapısı gelince eski yolun ne kadar kırılgan olduğunu herkes gördü. Hem debugging, hem destek süreçleri için REST API çağrısına geçmek ekibin hayatını kolaylaştırdı (buna dikkat edin)
Peki Doğru Yol Nedir? Ne Yapmalı?
Kural Net Ama Uygulanması Herkesin Aklına Gelmiyor
- Token sadece kimlik doğrular ve yetki kontrolünde kullanılır.
- Tüm gerçek verileri mutlaka API üzerinden alın.
- Tüm claim alanlarını anlık/tamamlayıcı kabul edin — her an uçabilirler.
Bakın, İnanın, Duyar gibiyim; “Ama Sen abi bunun maliyeti artıyor!” diyebilirsiniz haklısınız — fazladan API çağrısı hem geciktirir hem parasal yük getirir tabiî ki. Fakat kısa yol seçmenin acısını çok çektim ben… Daha geçenlerde minik bir startup canlıya geçtiğinde production ortamında bekledikleri claim yoktu, onboarding işlemleri komple kitlendi! Ufak tefek sandığınız hataların domino etkisi bazen tüm sistemi altüst ediyor…
Nereden Veri Almalı Peki?
- Eğer kullanıcı detayı lazım olursa Azure DevOps Profile API‘yi tercih edin — garantili çözüm budur.
- Ekip/organizasyon bilgisi gerekiyorsa yine resmî REST API’ye başvurun.
Buradaki anlaşma nettir; belgeler sürekli güncellenir ve değişiklik olunca bildirilir. - Mecbur kalmadıkça iş akışınızı sakın ola ki tokenda dolaşan değerlere bağlamayın!
API dediğin taş gibidir; bozulursa zaten versiyonlanır ya da migration rehberi çıkar.
Token işe köpükten heykel misali—birazdan şekil değiştirmiş olabilir.
Token Kullanımında Yapılan Tipik Hatalar
- Direkt claim bağımlılığı: Kodda login sonrası kullanıcı profili yerine token’daki claim’i kullanmak.
- Test ortamında token’la veri simülasyonu: Gerçek API yerine statik token’la test yapmak, release’de patlamalara açık kapı bırakıyor.
- Token formatına fazla bel bağlamak: Version upgrade’de claim’in formatı değişince eski kod dibe vuruyor.
Benim Önerim: API First Prensibi
Her projede, token’daki veriyle iş mantığı kurmak yerine, taş gibi API endpoint’lerinden veriyi çekmek hem sürdürülebilirlik hem de support açısından hayat kurtarıyor. Azure DevOps, Entra ID ve benzeri platformlarda resmî API dokümanlarını takip etmek inanın en güvenli yol.
Azure dünyasında kimlik yönetimi sürekli yeniden tasarlanıyor–detaylarına Azure SDK Ekim 2025 Yenilikler yazımda girdim bakabilirsiniz.
Sıkça Sorulan Sorular
“Ama production’da bugüne kadar sorun olmadı?”
Tamam, bugüne kadar claim yapısı değişmemiş olabilir ve sistemin sorunsuz çalışmış olabilir (en azından benim deneyimim böyle). Ama bu tamamen tesadüf – claim yapısı sessiz sedasız değişirse dün çalışan sistemin sabah bomboş cevap vermesine şaşmayın. Bunu test ortamında yaşadık; production’a çıkınca claim’in “email” alanı kaybolmuştu ve onboarding işlemleri kilitlendi.
“Çok fazla API çağrısı performansı öldürür mü?”
Vallahi, Evet, ekstra yük oluşturur ama cache veya ara katman mimarisiyle aşılabiliyor. Ben en iyi sonucu minimum claim kontrollü + backend cache edilmiş user profile ile aldım (Ankara ofiste gece-gündüz denedik). Mesela Redis cache ile profil verisini 15 dakika sakladık, API çağrısı sayısı dramatik şekilde düştü.
“Token decode etmek hiç mi kullanılamaz?”
Token decode etmek, sadece debugging veya anlık kontrol için pratik olabilir — fakat live sistemde, iş mantığında asla dayanak olarak kullanılmamalı. Bilhassa Azure DevOps ve Microsoft ekosisteminde “decode edilen veri” ile karar vermek, ileride baş ağrısı getiriyor.
“API ile veri çekmek hangi durumda zorunlu?”
Kullanıcıya özel veri, grup bilgisi, organizasyon dinamikleri gibi konular API ile çekilmeli. Token sadece “kimsin ve yetkilisin mi?” diyebildiği için, iş akışında gerçek verinin kaynağı her zaman API olmalı.
“Token içeriği değişirse geri dönmek kolay mı?”
Maalesef, claim formatı değişince eski kodun patch edilmesi günler, bazen haftalar alabiliyor. Mesela büyük kurumlarda saha testini, QA ve regression testleriyle birlikte yürütmek şart. Ben bir projede, claim değişimi sonrası 5 günlük patch süreci geçirdik, testlerin yarısı live ortamda ortaya çıktı.
Kapanışta Net Uyarım: Sakın Geç Kalmayın!
İtiraf edeyim, Bazılarınız okurken “Bizde risk yoktur…” diyebilir ama açık konuşayım—gördüğüm her beş kurumdan üçünün kodunda hâlâ direkt decode yöntemi kullanılıyor! Ve çoğu şirket böyle kritik konuları erteleye erteleye son haftaya bırakıyor… ciddi sıkıntılı sonuçlara sebep oluyor inanın bana.
- Eğer sizinkilerde hâlâ
.decode(),.parseJwt(), türevleri varsa bugün başlayın düzeltmeye. - Süre azaldıkça yapılan migrasyonlarda testlerin yarısı atlanıyor (bizzat yaşadığım örnek!), kullanıcı deneyimi dibe vuruyor.
- Kodunun sağlamlığından eminsen yalnızca resmî kanallardan veri topla – başka yolu yok…
Kapanış Tüyosu: Token ‘Read Only’, API ‘Guaranteed’
Şahsen, Token’ı sadece bir anahtar gibi kullan, API’yı işe kasanın tapusu gibi. Token’a dayalı iş mantığını bırakmak kısa vadede zorlasa da, uzun vadede hem sistemin hem ekibin başını ağrıtmıyor.
Azure Storage API’larında Entra ID ve RBAC Dönemi: Pratikte Ne Değişti? yazımı da inceleyebilirsiniz.
Kaynak: Authentication Tokens Are Not a Data Contract
Kaynaklar ve İleri Okuma
Azure Active Directory Access Tokens
Opaque Tokens Are Coming to Azure AD (Azure Blog)
Microsoft Authentication Library — Token Concepts
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder