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 halde değişecek gibi duruyor.
Neden Token İçeriğine Asla Güvenmemelisiniz?
Token = Post-it Kağıdı, API = Tapu Senedi
Kafanda banka kartını canlandır; üstünde isim 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) resmi 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 yani.
- Mimari büyüyüp gelişince arka planda formatlar tamamen evrim geçiriyor, eskiler rafa kalkabiliyor.
Tüm bunlara kulak tıkayıp illa ki gidip doğrudan token’dan veri çekerseniz… geçmiş olsun, kodda saati kurulmuş bomba sizi bekliyor!
Büyük Değişiklik Yolda: Artık Tokenlar OPAK Hale 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 ve 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 hala 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.
💡 Bilgi: Microsoft zaten çok uzun zamandır Azure DevOps tarafında token içeriklerini kamuya duyurmuyordu ve herhangi bir claim’in yapısı konusunda asla söz vermedi.
Yeni dönemde bu tavır iyice sertleşecek.
Yeni dönemde bu tavır iyice sertleşecek.
Açıkçası… İlk Morali Bozan Adam Ben Oldum!
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!
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.
İ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 tabii 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 resmi 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 ise köpükten heykel misali—birazdan şekil değiştirmiş olabilir.
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 hala
.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 resmi kanallardan veri topla – başka yolu yok…
💡 Bilgi: Bu konuda kafa karıştıracak kadar fazla yanlış pratik dönüyor ortalıkta.
Azure dünyasında kimlik yönetimi sürekli yeniden tasarlanıyor–detaylarına Azure SDK Ekim 2025 Yenilikler yazımda girdim bakabilirsiniz
.
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 Sorulanlar & Pratik Tüyolar
- Soru: “Ama production’da bugüne kadar sorun olmadı?”
Cevap: Tamamen tesadüfi kurtuluş 🙂 Claim yapısı sessiz sedasız değişirse dün çalışan sistemin sabah bomboş cevap vermesine şaşmayın… - Soru: “Çok fazla API çağrısı performansı öldürür mü?”
Cevap: işte burası önemli—tabii 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).
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
İçeriği paylaş:
Yorum gönder