Bir mobil uygulamayı ilk açtığınızda parolanızı girdiniz diyelim. Sonra “Hesabım” sekmesine bastınız ve… aynı parolayı bir daha girmek zorunda kaldınız. Tanıdık geldi mi?
Küçük bir detay: Bu dert, aslında CIAM tarafında yıllardır önümüze çıkıyor. Microsoft da geçtiğimiz günlerde Microsoft Entra External ID Native Authentication için GA duyurusunu yaptı — yanı native uygulamalardan embedded web view’lara doğrudan SSO senaryosu artık resmî olarak geldi. Ben burada hem teknik tarafını hem de Türkiye’deki kurumsal yapılarda nerede iş göreceğini anlatayım istedim.
Önce şunu söyleyeyim: bu özellik kağıt üstünde küçük görünüyor. Ama ben uzun zamandır bekliyordum, açık konuşayım. Çünkü hibrit uygulamalarda en sınır bozucu noktalardan biri tam da buydu.
Native Auth Neydi, Niye Bu Kadar Konuşuldu?
Bak şimdi, Geri saralım biraz. Klasik OAuth/OIDC akışında kullanıcıyı tarayıcıya yönlendiriyorsunuz; system browser olsun, in-app browser olsun, fark etmiyor, orada login oluyor. Sonra deep link ile uygulamaya geri dönüyor. Çalışıyor mu? Evet. Ama UX tarafı biraz kırılgan kalıyor.
Native Authentication işe olayı tersine çeviriyor: login ekranını siz kendi uygulamanızın içinde çiziyorsunuz, kendi tasarımınızla, kendi akışınızla, hatta isterseniz kendi animasyonunuzla (şey, biraz uğraştırır. Mümkün). Arkada SDK ya da direkt API çağrılarıyla Entra External ID konuşuyor. Tarayıcı görünmüyor. Kullanıcı da “nerede login öldüm ben şimdi” diye düşünmüyor.
Şimdi gelelim işin can alıcı noktasına.
Geçen yıl bir e-ticaret müşterimizde — orta ölçekliydi, yaklaşık 800 bin aktif kullanıcısı olan bir mobil uygulama — bu yapıya geçmiştik. Login dönüşüm oranı %12 civarında arttı. Yanı 100 kişiden 12’si daha “tamam bırakıyorum” demedi. Kurumsal CIAM dünyasında bu hiç küçümsenecek bir fark değil.
Fakat işin içinde bir pürüz vardı.
Açık konuşayım, WebView’lar.
Peki Asıl Problem Neydi?
İşin aslı şu: artık “tamamen native” diye bir şey yok gıbı. Hangı mobil uygulamaya baksanız içinde mutlaka bir embedded web view var. Niye var? Çünkü profil yönetimi sürekli değişiyor, ödeme akışları PCI-DSS yüzünden çoğu zaman web’e kayıyor, sadakat sayfaları pazarlama ekibinin elinde oluyor, destek merkezî de genelde dışarıdan gelen bir SaaS çözümüne bağlanıyor.
Kısacası uygulama native başlıyor ama yarıda web’e dönüyor. Ve tam burada işler karışıyor.
Kullanıcı native login öldü diyelim. Sonra “Cüzdanım” dedi ve WebView açıldı. Web tarafı kullanıcıyı tanımıyor; çünkü WebView’ın cookie deposu sistem tarayıcısından ayrı duruyor (ben de ilk duyduğumda şaşırmıştım). Sonuç? Bir login daha. Belki bir tane daha. Kullanıcı yoruluyor, kapatıyor, gidiyor (şaşırtıcı ama gerçek)
“Bir bankacılık projesinde sırf bu yüzden ekstra bir silent login iframe’i yazmıştık. İğrenç bir hack’ti. Şimdi dönüp bakınca biraz utanıyorum.” — kendi kendime, geçen hafta.
GA ile Tam Olarak Ne Geldi?
İtiraf edeyim, Microsoft’un bu sürümle çözdüğü mesele yukarıdaki akışın ta kendisi. Native tarafta aldığınız access token’ı embedded web view’a taşıyorsunuz; yanı köprü kuruyorsunuz diyeyim. Web tarafı token’ı görüyor, doğruluyor ve kullanıcıyı tanıyor. Bitti gitti.
Akış kabaca şöyle:
- Kullanıcı native UI üzerinden sign-in ölür (SDK veya direkt API ile)
- Uygulama geçerli bir access token alır
- WebView hedef URL’yi yüklerken
Authorization: Bearer <access_token>header’ını ekler - Web kaynağı token’ı validate eder ve oturum açılır
- Kullanıcı ikinci kez parola girmez — bunu es geçmeyin
Şimdi iOS tarafından basit bir örnek verelim (WKWebView):
// Native Auth ile token aldıktan sonra
let token = authResult.accessToken
var request = URLRequest(url: URL(string: "https://hesabim.sirketim.com/cuzdan")!)
request.setValue("Bearer \(token)", forHTTPHeaderField: "Authorization")
let webView = WKWebView(frame: view.bounds)
webView.load(request)
view.addSubview(webView)
Android tarafında da mantık hemen hemen aynı; WebView.loadUrl(url, headersMap) ile header injection yapıyorsunuz. İlk istek için tabi. Sonraki sayfa geçişlerinde token’ın oturum cookie’sine dönüşmesi gerekiyor — bunu web tarafının halletmesi lazım, yoksa olay yarım kalıyor.
Kısa bir not düşeyim buraya.
Kritik küçük detay
Bak şimdi, Buna özellikle dikkat edin: Bearer header sadece ilk request’e enjekte ediliyor (inanın bana). Kullanıcı WebView içinde başka bir linke tıklarsa browser engine yeni request’te o header’ı taşımıyor olabilir. O yüzden web uygulamanızın token’ı alıp kendi session cookie’sine çevirmesi gerekiyor. Yoksa SSO sadece giriş sayfasında çalışır, sonra hop diye bozulur. İlk denememde ben de tam bu hataya düştüm; staging’de saatlerce uğraşıp “niye ikinci sayfada yine login istiyor lan bu” diye söylenmiştim. Bu konuyla ilgili GitHub App Token Formatı Değişiyor: ghs_ Sonrası Yeni Dönem yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için Kubelet Fine-Grained Authorization GA: nodes/proxy Devri yazımıza bakabilirsiniz.
Türkiye’deki Kurumsal Müşteriler İçin Ne Anlama Geliyor?
Şimdi gelelim benim sevdiğim yere. Türkiye’de CIAM (Customer Identity & Access Management) tarafı hâlâ çok olgun değil diyebilirim. Birçok şirket user table tutuyor, bcrypt ile parola hash’liyor ve sonra da “biz IAM’i içeride çözdük” diye gurur duyuyor (inanın bana). Açık konuşayım, bu gurur bazen pahalıya patlıyor.
Hmm, bunu nasıl anlatsamdı… Bu konuyla ilgili Kubernetes v1.36’da User Namespaces GA: Rootless Devri Geldi yazımıza da göz atmanızı tavsiye ederim.
Perakende, telekom, bankacılık dışı finans; yanı fintech’ler, sigorta şirketleri ve ödeme kuruluşları için bu özellik baya iş görebilir (evet, doğru duydunuz). Çünkü bu sektörlerdeki uygulamalar çoğu zaman hibrit yapıda ilerliyor: native shell var, onun içine serpiştirilmiş birkaç web modülü var.
Yanı, Bir sigorta şirketini düşünün mesela. Ana ekran native ölür; poliçeler görünür, hızlı işlemler akar gider. Ama “Hasar Bildirimi” kısmı tamamen web olabilir. Compliance kuralları haftadan haftaya değişir (ve evet, o kısım genelde kimsenin sevmediği yerdir). Eski dünyada kullanıcı hasar bildirimi için tekrar login ölüyordu; yeni dünyada buna gerek kalmıyor.
Bu arada bunu yakın zamanda Microsoft Agent Framework’te Chat History: Nerede yazısında değindiğim “stateful identity” konusu ile yan yana koyunca ortaya daha düzgün bir kurumsal mimarı çıkıyor aslında.
Peki Eski Yöntemle Yeni Yöntem Arasında Ne Fark Var?
Garip gelecek ama, Lafı gevelemeden tabloya bakalım; böyle daha net oluyor:
| Senaryo | Eski (Browser-based OAuth) | Yeni (Native Auth + WV SSO) |
|---|---|---|
| Login UX | Tarayıcı açılır, geri döner | Tamamen in-app, native |
| WebView’a geçiş | Tekrar login gerekir | Sessizce devam eder |
| Branding kontrolü | Kısıtlı (browser chrome) | Tam kontrol sizde ölür |
| Implementasyon eforu | Düşük-orta | Orta (SDK + WV köprüsü) |
| Token güvenliği | User agent izole eder | App memory’de kalır — dikkat ister! |
Sondaki satırı atlamayın derim. Native Auth’un ufak ama önemli bir trade-off’u var: token artık system browser gıbı ayrı ve izole bir yerde durmuyor; sizin uygulamanın belleğinde dolaşıyor olabilir. Yanı root/jailbreak detection, certificate pinning ve secure storage gıbı konulara daha ciddi bakmanız lazım. Bunları zaten yapıyorsanız sorun yok gıbı; yapmıyorsanız başlamanın tam sırası.
Bunu Startup mı Kullanır Enterprise mı?
Doğrusu, Açık konuşayım: herkes için aynı derecede gerekli değil bu özellik.
Küçük ekipseniz / startup’sanız
Eğer 10-50 bin kullanıcılı bir uygulamanız varsa ve yapı hem mobil hem web hibritse, evet değer görürsünüz. Ama şunu da bilmek lazım: Native Auth’a geçmek tek tuşluk iş değil. SDK entegrasyonu var, MFA akışını yeniden çizmeniz gerekebilir, hata yönetimi ayrı konu (inanın bana). Bir senior mobile developer için kabaca 2-4 hafta sürebilir diye tahmin ediyorum; tabii proje karmaşıksa uzar da uzar.
Büyük organizasyonsanız / enterprise iseniz
Burası farklı oynuyor.
Bir bankanın ya da 5 milyon+ kullanıcılı perakende uygulamasının her ekstra login prompt’u ciddi gelir kaybına dönebilir.
Bu durumda Native Auth + WebView SSO baya mantıklı duruyor.
Ama ufak bir not düşeyim: kurumsal yapılarda IAM kararları çoğunlukla merkezden alındığı için mobil ekiple identity ekibinin birlikte oturması şart.
Ben Logosoft’ta bir telekom projesinde tam burada takılmıştık; mobil ekip “hallederiz” dedi, identity ekibi “ama compliance?” dedi. Konu üç ay boyunca masada döndü durdu.
Erken konuşun derim.
Klasik Entra ID (eski adıyla Azure AD) workforce tenant’larında bu özellik yok.
Yanı çalışan girişleri için değil, müşteri girişleri için tasarlanmış.
Maliyet Tarafına TL Gözlüğüyle Bakınca Ne Görüyoruz?
Entra External ID fiyatlandırması MAU (Monthly Active Users) bazlı geliyor. İlk 50.000 MAU ücretsiz; ki çoğu Türk startup’ı için fena olmayan bir eşik bu. Sonrası tier’lı ilerliyor; kabaca 50K-100K arasında kullanıcı başına çok düşük cent seviyeleri görüyorsunuz ve üstü de kademeli olarak aşağı iniyor.
İşte tam da bu noktada devreye giriyor.
Bunu kendi IAM’ınızı içeride tutmanın maliyetiyle kıyaslayın derim:
- bir senior backend developer’ın yıllık maliyeti var;
- security audit masrafı var;
- parola sıfırlama altyapısı var;
- SMS OTP entegrasyonu var;
- MFA implementasyonu var; — ciddi fark yaratıyor
Tüm bunları toplayınca tablo biraz değişiyor.
200K MAU altındaysanız Entra External ID çoğu senaryoda daha ucuz çıkabiliyor.
Üstünde de tartışılır elbette ama operasyonel rahatlık bazen fiyat farkını sessizce kapatıyor.
Bir de şunu ekleyeyim:
Axios npm Saldırısı: Azure Pipelines Kullananlar İçin Rehberwritesinde değindiğim gıbı supply chain saldırılarının arttığı dönemde hayatı altyapıyı,
özellikle authentication katmanını,
managed servise bırakmak bence risk azaltma açısından da fena fikir değil.
Nereden Başlayayım Diyenler İçin İlk Adımlar
- Bir External ID tenant oluşturun — Azure portal üzerinden external tenant olarak.
Workforce tenant ile karıştırmayın! - User flow tanımlayın — sign-up/sign-in,
attribute’lar,
MFA seçenekleri.
Burada acele etmeyin,
sonra geri dönüp düzeltmesi can sıkıyor. - Native Auth SDK’sını projeye ekleyin — iOS,
Android ya da React Native için ayrı SDK’lar mevcut. - Web tarafını hazırlayın — Bearer token kabul edip bunu kendi session’una çevirebilen middleware yazın.
ASP.NET Core kullanıyorsanızJwtBearermiddleware ile on dakikalık iş gıbı duruyor. - WebView wrapper yazın — token injection için merkezî helper class kurun.
Dağınık bırakmayın,
sonra debug etmek bela oluyor. - Token expiry handling ekleyin — süre dolunca silent refresh deneyin,
olmazsa native login’e geri dönün.
Bu kısım gözden kaçarsa akış yarıda kalır.
Beşinci. Altıncı adımı hafife almayın derim.
En çok problem orada çıkıyor,
garip şekilde hep orası dağılıyor.
Eksik Bulduğum Yanlar
Her şey yerli yerinde gıbı duruyor ama…
Microsoft’un Native Auth dokümantasyonu hâlâ biraz parçalı.
Sample app’ler var evet,
fakat production-ready hissettirmiyor çoğu;
bir miktar boilerplate yazmanız gerekiyor.
Cross-platform tarafta özellikle Flutter hâlâ geride kalmış durumda.
React Native iyi gidiyor,
MAUI idare ediyor,
ama Flutter geliştiricileri şimdilik community-driven çözümlere bakmak zorunda kalabilir.
Umarım önümüzdeki çeyrekte bu boşluk kapanır;
bakalım göreceğiz.
Bir de token rotation ve refresh token handling tarafında,
özellikle güvenlik politikalarınız sıkıyorsa
(mesela access token ömrü 5 dakika işe),
WebView içinde o refresh dansı pek keyif vermiyor.
Bu noktada Microsoft’un biraz daha net guidance vermesi gerektiğini düşünüyorum açıkçası.
Sıkça Sorulan Sorular
Native Authentication ile MSAL arasında ne fark var?
MSAL klasik OAuth akışını yönetiyor — yanı tarayıcı tabanlı çalışıyor. Bakın, native Authentication işe tarayıcıyı tamamen aradan çıkarıyor; login ekranını siz kendi uygulamanızda çiziyorsunuz. Aslında UX kontrolü tamamen sizde oluyor, ama açıkçası sorumluluk da o oranda artıyor.
Bu klasik Azure AD (workforce) tenant’larında da çalışır mı?
Hayır, maalesef. Native Authentication şu an sadece Microsoft Entra External ID tenant’larına özel — yanı müşteri kimlik senaryoları için tasarlanmış. Çalışan kimliği için kullanmak istiyorsanız işe yaramıyor.
WebView’a token’ı header ile geçirmek güvenli mi?
Şahsen, Evet. Tabii ki HTTPS kullanıyorsanız ve WebView yapılandırmanız doğruysa. Cleartext HTTP’ye asla token enjekte etmeyin — bence bu en kritik nokta. Bir de şu var: üçüncü parti URL’leri WebView’da açıyorsanız, Authorization header’ını sadece kendi domain’lerinize göndermeye dikkat edin, yoksa token leak riski gerçekten ciddi.
Kullanıcı WebView içinde başka bir sayfaya geçerse SSO devam eder mi?
Bu tamamen web tarafının nasıl implemente edildiğine bağlı (yanlış duymadınız). Mesela web uygulamanız ilk request’teki Bearer token’ı alıp kendi session cookie’sine dönüştürüyorsa, evet, sonraki sayfalarda kullanıcı login kalmaya devam eder. Ama bu dönüşüm yoksa, hani sadece ilk sayfa SSO oluyor, gerisinde değil.
Native Auth’a geçmek ne kadar sürer?
Tek platform için — mesela sadece iOS — deneyimli bir geliştiriciyle sıfırdan entegrasyon kabaca 2-3 hafta tutuyor. Ama mevcut MSAL tabanlı bir düşüneyim… bir akıştan migrate ediyorsanız, tecrübeme göre edge case’ler. Testler dahil 4-6 haftaya rahatlıkla çıkabiliyor. Acele etmeyin, MFA ve error handling’i sakın atlamamaya bakın.
Kaynaklar ve İleri Okuma
Microsoft Identity DevBlog: Native Auth SSO GA Duyurusu
Ne yalan söyleyeyim, Microsoft Learn: Native Authentication Concepts
Microsoft Entra External ID for Customers — Genel Bakış
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.
