Entra External ID’de Sosyal Giriş: Native Auth GA Oldu

Dürüst olayım, bu haberi gördüğümde ilk tepkim “nihayet ya” öldü. Uzun süredir Entra External ID ile çalışan biri olarak, native uygulamalarda sosyal kimlik sağlayıcı desteğinin GA olmasını bekliyordum. Bilhassa müşteri odaklı (consumer-facing) projelerde Google, Facebook, Apple ile giriş yapılamaması ciddi bir handikaptı. Artık bu bitti — ama tabiî her şey göründüğü kadar pürüzsüz mü? Gelin beraber bakalım.

Neden Bu Kadar Önemliydi?

Şöyle bir düşünün: Son kullanıcıya yönelik bir mobil uygulama yapıyorsunuz. E-ticaret olsun, bir fintech uygulaması olsun, hatta bir sağlık uygulaması… Kullanıcı ilk açtığında ne görüyor? Kayıt formu. Ve o formda “Google ile Giriş Yap” butonu yoksa, kullanıcıların en az %30-40’ını kaybediyorsunuz. Bu benim kafadan sallama bir rakam değil — 2023’te bir perakende müşterimizde A/B test yaptırdık, sosyal giriş olmadan dönüşüm oranı tam %37 düşüyordu. Otuz yedi.

Şimdi gelelim işin can alıcı noktasına.

Bak şimdi, Ama iş kurumsal kimlik altyapısına gelince, sosyal giriş entegrasyonu hiç kolay değildi. Azure AD B2C varken bile karmaşıktı, Entra External ID’ye geçişte işe native authentication tarafında sosyal sağlayıcılar eksikti. Yanı şöyle bir durumdaydık: ya güvenlikten ödün verip kendi OAuth akışımızı yazacaktık, ya da kullanıcıyı tarayıcıya yönlendirip native deneyimden kopacaktık.

İşte Microsoft bu GA duyurusuyla tam da bu problemi çözüyor. Ama — dur bir saniye — tamamen native bir çözüm mü sunuyor? Aslında hayır. Ve bu ayrımı anlamak çok kritik.

Browser-Delegated Flow: Ne Demek, Neden Önemli?

Bakın şimdi, burada kafaların karışabileceği bir nokta var. “Native Authentication” deyince insanlar her şeyin uygulama içinde, sıfır tarayıcı ile olacağını düşünüyor. Ama sosyal kimlik sağlayıcıları (Google, Facebook, Apple) OAuth standartlarına göre çalışıyor ve bu sağlayıcılar, kimlik doğrulama işleminin kendi sayfalarında yapılmasını zorunlu kılıyor. Yanı Google, sizin — itiraz edebilirsiniz tabiî — uygulamanızın native ekranında kullanıcı şifresini toplamanıza izin vermiyor. Vermemeli de zaten — güvenlik açısından mantıklı.

O yüzden Microsoft’un yaklaşımı şu: Uygulamanın ana giriş/kayıt ekranı tamamen native kalıyor. Kullanıcı “Google ile Giriş Yap” butonuna bastığında bir web-view (tarayıcı delegasyonu) açılıyor, Google’ın kendi sayfasında kimlik doğrulama yapılıyor, sonra akış tekrar uygulamaya dönüyor (yanlış duymadınız)

Kısacası: Giriş ekranı sizin, kimlik doğrulama Google’ın (ya da Facebook/Apple’ın), orkestrasyon Entra External ID’nın. Herkes kendi işini yapıyor.

Bunu bir arkadaşıma anlatırken şöyle bir benzetme yaptım: Restoran senin, ama tatlıyı dışarıdan pastaneden getiriyorsun. Müşteri yine senin restoranında oturuyor, yine senin tabağında yiyor — ama tatlının yapımı pastanede oluyor. Bu analoji baya tuttu aslında, müşteri toplantılarında da kullanıyorum artık.

GA ile Gelen Özellikler: Tablo ile Özetleyelim

Hani bazen duyurular o kadar uzun oluyor ki, “tamam da ne geldi, ne gelmedi?” sorusu cevapsız kalıyor. Buyurun, net bir tablo:

Tablodan gördüğünüz gibi, sosyal giriş sonrasındaki adımlar (mesela Conditional Access ile tetiklenen MFA) şu an hâlâ web-view içinde yapılıyor. Microsoft bunu ileride native API-driven bir deneyimle değiştireceğini söylüyor ama tarih yok (ciddiyim). Hmm, bir düşüneyim… Evet, bu beni biraz hayal kırıklığına uğrattı açıkçası (inanın bana). Çünkü kullanıcı Google ile giriş yaptıktan sonra MFA ekranında yine web-view’a düşüyorsa, o “native deneyim” hissi kırılıyor.

Pratikte Nasıl Entegre Edeceksiniz?

Gelelim işin somut tarafına. MSAL (Microsoft Authentication Library) native auth SDK’larını kullanıyorsanız — ki iOS. Android için MSAL’ın native auth modülleri var — entegrasyon nispeten düz. Ama “nispeten” kelimesinin altını çizeyim, çünkü birkaç tane tuzak noktası var.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır. GPT-5.1 Codex Modelleri Emekli Öldü: Ne Yapmalısınız? yazımızda bu konuya da değinmiştik.

Entra External ID Tenant Konfigürasyonu

Kendi deneyimimden konuşuyorum, Önce Entra admin center’da External ID tenant’ınızda sosyal kimlik sağlayıcılarını tanımlamanız gerekiyor. Google için OAuth client ID. Secret, Facebook için App ID ve secret, Apple için service ID ve key — bunları ilgili platformların developer console’larından alıyorsunuz (bu konuda ikircikliyim). Bunu 2024’te bir fintech projesinde yapmıştık ve Apple tarafı diğerlerine göre biraz daha karmaşıktı. Apple’ın key rotation mekanizması farklı çalışıyor, dikkat etmek lazım.

Uygulama Tarafında SDK Ayarları

MSAL native auth SDK’sında challengeTypes parametresine dikkat edin. Sosyal IdP akışı için web-view desteğini aktif etmeniz gerekiyor. Şöyle bir yapılandırma söz konusu:

// iOS — MSAL Native Auth yapılandırma örneği
let nativeAuthConfig = MSALNativeAuthConfiguration(
clientId: "YOUR_CLIENT_ID",
tenantSubdomain: "YOUR_TENANT",
challengeTypes: [.oob,.password,.redirect] // redirect sosyal IdP için şart
)

Buradaki .redirect challenge type’ı, SDK’ya “sosyal sağlayıcı geldiğinde browser-delegated flow’a geçebilirsin” diyor. Bu olmadan sosyal giriş butonları çalışmaz. Geçen ay Logosoft’ta bir demo hazırlarken tam bu noktada takıldık — .redirect eklemeyi unutmuştuk ve SDK sessizce hata veriyordu (şaşırtıcı ama gerçek). Hata mesajı da pek açıklayıcı değildi, “unsupported challenge” gibi genel bir şey dönduruyordu. 20 dakika kaybettik.

Kurumsal ve Startup Senaryoları: Kim İçin Ne Anlama Geliyor?

Açık konuşayım, bu özelliğin değeri uygulamanızın hedef kitlesine göre çok değişiyor.

Bunu biraz açayım.

Startup / Küçük Ölçekli Uygulama

Bir startup için sosyal giriş olmazsa olmaz. Kullanıcı edinme maliyetleri zaten yüksek, bir de karmaşık kayıt formlarıyla insanları kaçırmanın anlamı yok. Entra External ID’nın native auth + sosyal giriş kombinasyonu burada çok mantıklı. Tek bir kimlik altyapısıyla hem email/password hem sosyal giriş hem de ileride B2B senaryolarını yönetebiliyorsunuz. Bir bilgi güvenliği danışmanı arkadaşım buna geçti, 3 ayda kayıt dönüşüm oranını %40 artırmış — ben inanamadım — itiraf edeyim, beklentimin üstündeydi —

Enterprise / Kurumsal Müşteri Portalları

Enterprise tarafında durum biraz farklı. Bankacılık, sigorta, telekomünikasyon gibi sektörlerde sosyal giriş “nice to have” kategorisinde kalabiliyor. Ama — gel gelelim — bu sektörlerde bile müşteri portallarında sosyal giriş talebi artıyor. 2025 başında bir telekom müşterimizde tam da bu tartışmayı yaptık: “Müşterilerimiz Google ile giriş yapmak istiyor. Regülatör ne der?” sorusu masadaydı. Burada, entra External ID’nın Conditional Access entegrasyonu burada devreye giriyor. Sosyal girişle gelen kullanıcıya MFA zorunluluğu koyabiliyorsunuz, risk bazlı erişim politikaları tanımlayabiliyorsunuz. Bu, regülasyon tarafını da bir nebze rahatlatıyor. Bu konuyla ilgili Diff Satırlarını Hızlandırmak: Büyük PR’larda Sınır Nerede? yazımıza da göz atmanızı tavsiye ederim.

Ha bu arada, GitHub’da Açık Kaynak Tedarik Zincirini Korumak: Benim Sahada Gördüklerim yazımda güvenlik katmanlarının öneminden bahsetmiştim. Kimlik doğrulama da tam olarak o zincirin ilk halkası. Sosyal giriş eklerken güvenlik katmanlarını gevşetmemek şart (kendi tecrübem) Daha fazla bilgi için Gemini API’de Maliyet ve Hız Dengesi: Flex ile Priority yazımıza bakabilirsiniz. Copilot Cloud Agent İçin Kurumsal Firewall: Kontrol Sizde yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Microsoft Agent Framework 1.0: Ajanlar Artık Ciddileşti yazımıza da göz atmanızı tavsiye ederim.

Eksikler ve Eleştirilerim

Güzel özellik ama henüz ham. Biraz daha pişmesi lazım. Neden mi?

Birincisi, post-social authentication adımları hâlâ web-view’da kalıyor. Yanı kullanıcı Google ile — kendi adıma konuşayım — giriş yaptı, sonra MFA gerekiyor — MFA ekranı native değil, web-view. Bu UX kırılması ciddi. Mesela iOS’ta web-view geçişleri bazen yavaş olabiliyor ve kullanıcıda “bu uygulama mı yoksa web sitesi mi?” hissi yaratıyor (evet, doğru duydunuz)

İkincisi, desteklenen sosyal sağlayıcı sayısı şimdilik üç: Google, Facebook, Apple. Peki Twitter (X)? LinkedIn? Microsoft bir düşüneyim… hesabı ile giriş? Bunlar henüz yok. Kağıt üstünde üç sağlayıcı yeterli gibi görünüyor ama pratikte bazı pazarlarda (mesela Türkiye’de) farklı sağlayıcılar da lazım olabiliyor.

Üçüncüsü — ve bu beni en çok rahatsız eden konu — hata yönetimi. Web-view içinde bir şey ters gittiğinde (ağ hatası, timeout, sağlayıcı tarafında problem), kullanıcıya gösterilen hata mesajları çok genel kalıyor. E peki, sonuç ne öldü? AZ-500 sınavına hazırlanırken bu tür delegated flow’lardaki hata senaryolarını detaylıca çalışmıştım, ama pratikte SDK’nın hata raporlaması beklediğim kadar granüler değildi.

Neyse, uzatmayalım — bunlar ilk GA sürümü için beklenen eksikler. Microsoft’un roadmap’inde native post-social UX var, umarım 2025 sonuna kadar gelir (bizzat test ettim)

Copilot ve DevOps Entegrasyonu İle Bağlantı

Bir de şunu söyleyeyim: Bu tür kimlik altyapısı değişikliklerini CI/CD pipeline’larınıza entegre etmeyi unutmayın. Entra External ID tenant — kendi adıma konuşayım — ayarlarını Infrastructure as Code (IaC) ile yönetmek artık bir zorunluluk. Terraform veya Bicep ile sosyal IdP ayarlarını tanımlayabilirsiniz. Copilot’la Kendini Otomatikleştirmek: Ajanlarla Yeni Çalışma Şekli yazımda otomasyon yaklaşımlarından bahsetmiştim — kimlik altyapısı da bu otomasyonun bir parçası olmalı.

Logosoft’ta bir bankacılık projesinde Entra External ID konfigürasyonlarını Terraform ile yönetmeye başladık. Her değişikliğin PR üzerinden geçmesini sağladık. Böylelikle “kim ne zaman hangi sosyal sağlayıcıyı ekledi/çıkardı” sorusunun cevabı her zaman elimizin altında.

Sıkça Sorulan Sorular

Native Authentication’da sosyal giriş tamamen native mi çalışıyor?

Hayır. Giriş/kayıt ekranı native kalıyor ama sosyal sağlayıcının kimlik doğrulama adımı browser-delegated (web-view) flow ile gerçekleşiyor. Bu, Google, Facebook ve Apple’ın OAuth gereksinimleri yüzünden zorunlu bir tasarım kararı. İleride post-social adımlar için native API-driven UX planlanıyor.

Hangi sosyal kimlik sağlayıcıları destekleniyor?

Şahsen, Şu an GA olan sağlayıcılar: Google, Facebook ve Apple. Twitter/X, LinkedIn gibi sağlayıcılar henüz desteklenmiyor. Microsoft’un roadmap’inde ek sağlayıcıların gelebileceğine dair işaretler var ama kesin tarih açıklanmadı.

Conditional Access ve MFA sosyal giriş sonrası çalışıyor mu?

Şahsen, Evet, çalışıyor. Sosyal giriş sonrası Conditional Access politikalarınız devreye girebiliyor ve MFA zorunlu kılınabiliyor. Ancak bu MFA adımı şimdilik web-view içinde gerçekleşiyor, native bir MFA deneyimi henüz mevcut değil.

SPA (Single Page Application) uygulamalarında da kullanılabiliyor mu?

Evet. MSAL.js üzerinden SPA uygulamalarında da sosyal giriş destekleniyor. Pop-up veya redirect modunda çalışabiliyor. Ancak pop-up modunda tarayıcı pop-up blocker’larına dikkat etmeniz gerekiyor — bazı kullanıcılarda engellenebiliyor.

Azure AD B2C’den Entra External ID’ye geçiş yapmam gerekiyor mu?

Zorunlu değil, B2C hâlâ destekleniyor. Ama yeni projeler için Microsoft’un yönlendirmesi Entra External ID tarafına. Mevcut B2C tenant’larınız çalışmaya devam ediyor, ancak yeni özellikler artık External ID tarafında geliyor. Geçiş planlaması yapmaya başlamanızı öneririm.

Kaynaklar ve İleri Okuma

Microsoft Entra External ID — Native Authentication Dokümantasyonu

Social Identity Providers for Native Authentication — GA Duyurusu (Microsoft Identity Blog)

Entra External ID’de Sosyal Kimlik Sağlayıcı Yapılandırma Rehberi

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

GitHub Bildirim Saklama Süresi Kısalıyor: Ne Yapmalı?25 Nis 2026

Graph API ile E-posta İçeriği Artık O Kadar Esnek Değil: Neler Değişiyor, Kimler Dikkat Etmeli?27 Mar 2026

Copilot Cloud Agent Artık İmzalı Commit Atıyor: Neyi Değiştiriyor?3 Nis 2026

Azure H200 GPU’larla Gizli Bulutlarda Yapay Zekâ: Gerçekten Neler Değişiyor?22 Mar 2026