Entra External ID Native Auth SSO: Tam Entegre Deneyim
Hani, Geçen ay bir fintech müşterimizde tam olarak şu sahneyi yaşadık: Kullanıcı mobil uygulamada rahatça giriş yapıyor, sonra ödeme sayfasına geçince — pat! — yine login ekranı çıkıyor. Adam telefonu masaya bıraktı, “ben bunu kullanmam” dedi. Neden önemli bu? Hikâye orada koptu.
İşin garibi, İşte bu yüzden Microsoft’un Entra External ID tarafında Native Authentication için SSO desteğini GA’ya alması beni bayağı heyecanlandırdı. Ama dur, hemen alkış tutmayayım; kağıt üstünde tatlı duran şeyler pratikte bazen ufak bir taş gibi ayağa batıyor. Neyse, sırayla gidelim.
Sorun ne? Neden bu kadar can sıkıyor?
Bakın, mobil uygulama yazan herkes şunu bilir: Uygulamanızın her parçası native olmaz. Olmuyor işte. Profil sayfası var, ödeme formu var, destek alanı var, sadakat ekranı var; bunların çoğu web view içinde açılıyor çünkü hepsini tek tek native yazmak hem masraflı hem de gereksiz yorucu oluyor.
Çok konuştum, örnekle göstereyim.
E asıl mesele burada başlıyor: Kullanıcı native tarafta giriş yapıyor, tamam. Ama embedded web view açılınca tarayıcı session’ıyla bağı kalmıyor, cookie paylaşımı da yok, state de ayrı gidiyor. Yanı kullanıcı “ben az önce login olmuştum ya” diye bakarken karşısında tekrar login ekranını görüyor.
Bakın, Bu durum CIAM projelerinde ciddi sürtünme yaratıyor. Conversion düşüyor, insanlar uygulamayı terk ediyor, destek talepleri artıyor. 2023’te bir e-ticaret işinde buna benzer şeyi custom token relay ile çözmeye çalışmıştık — 3 hafta sürdü. Sonunda “biz bunu doğru mu kurduk acaba” diye birbirimize bakıp durmuştuk (inanın bana). Şimdi Microsoft bunu kutudan çıkar çıkmaz veriyor.
Native Auth SSO nasıl çalışıyor?
Mekanizma aslında basit görünüyor ama detaylar önemli. Şöyle düşünün:
- Kullanıcı native SDK veya API üzerinden giriş yapıyor
- Uygulama geçerli bir access token alıyor
- Embedded web view açılırken request header’a
Authorization: Bearer <access_token>ekleniyor - Web tarafındaki kaynak token’ı doğruluyor ve erişim veriyor (bence en önemlisi)
Yanı özünde token tabanlı bir oturum devamlılığı var. Tarayıcı cookie’sine yaslanmıyorsunuz. WKWebView’da da çalışıyor, Android WebView’da da. Bu nokta baya can alıcı çünkü — bir dakika, bunu da söyleyeyim — Apple’ın WKWebView tarafındaki cookie izolasyonu yüzünden eskiden bu iş gerçekten baş ağrıtıyordu.
// iOS — WKWebView ile SSO token enjeksiyonu (basitleştirilmiş örnek)
let webView = WKWebView(frame: view.bounds)
var request = URLRequest(url: URL(string: "https://app.example.com/profile")!)
request.setValue("Bearer \(accessToken)", forHTTPHeaderField: "Authorization")
webView.load(request)
Garip gelecek ama, Gördüğünüz gibi kontrol sizde kalıyor. Token’ı nasıl inject edeceğiniz, hangi isteklere ekleyeceğiniz neredeyse tamamen sizin mimarinize bağlı (ki bu çoğu kişinin gözünden kaçıyor). Bence bu esneklik iyi bir şey; çünkü her uygulamanın omurgası aynı değil zaten.
Bunu biraz açayım.
Türkiye’deki CIAM projelerinde durum nasıl?
Açık konuşayım: Türkiye’de CIAM kavramı hâlâ tam oturmuş değil. Birçok şirkette “identity” denince akla sadece Active Directory ve iç kullanıcı yönetimi geliyor. Oysa dışarıya açık uygulamalar — müşteri portalları, mobil bankacılık, e-ticaret platformları — burada External ID ile daha doğal dürüyor.
Logosoft’ta son bir yılda 3 farklı müşteride External ID değerlendirmesi yaptık. Bankacılık sektöründeki bir müşterimizde mobil uygulama içinden webview ile kredi başvuru formu gösteriliyordu. Kullanıcı. Oturum açmış olmasına rağmen kredi formuna geçince yeniden doğrulama isteniyor, üstüne bir de SMS OTP çıkıyordu. Kullanıcı deneyimi resmen dağılıyordu; bu yeni SSO özelliği tam böyle senaryolar için cuk oturuyor.
Bunu biraz açayım.
Ama başka bir gerçek daha var: Türkiye’deki şirketlerin büyük kısmı KVKK. BDDK regülasyonları yüzünden token’ları web view’a taşımaya çekiniyor. “Ya token çalınırsa?” sorusu hep masada dürüyor (ciddiyim). Burada şunu söyleyebilirim ki Entra External ID’nın token’ları kısa ömürlü oluyor (genelde 1 saat), ayrıca web view izole çalıştığı için tarayıcı extension gibi risklerden de biraz uzak kalıyorsunuz. Yine de hassas finansal işlemlerde step-up authentication düşünmek lazım; yanı işi tamamen gevşek bırakmamak gerekiyor. Daha fazla bilgi için
P2 planına geçtiğinizde risk-based conditional access ve identity protection gibi şeyler geliyor tabiî ki (şaşırtıcı ama gerçek). Bunlar finans ve sağlık sektörü için önemli ama küçük bir SaaS startup’ı için fazladan yük olabilir. Bütçe sıkışıksa P1 ile başlamak daha mantıklı geliyor; ihtiyaç büyüdükçe yukarı çıkarsınız.
Peki ilk adımlar nasıl?
İtiraf edeyim, Bunu projeye almak istiyorsanız sırayı çok dağıtmadan şöyle ilerleyin: Daha fazla bilgi için
1\. Entra External ID tenant oluşturun
Azure Portal’da “Microsoft Entra External ID” diye aratıp yeni tenant açın. Bu tenant mevcut Entra ID tenant’ınızdan ayrı olacak — karıştırmayın. İlk kurulum bana yaklaşık 10 dakika sürdü. DNS doğrulaması biraz uzayabiliyor,hani o kısım bazen insanın sabrını test ediyor.
2\. Native Authentication’ı aktif edin
Peki, garip gelecek ama, “Authentication methods” bölümüne girip Native Authentication özelliğini enable edin. Sonra bir App Registration oluşturun ve MSAL SDK’yı projeye ekleyin. iOS tarafında MSAL.framework,Android tarafında MSAL Android kullanıyorsunuz. Basit görünüyor,ama detaylarda minik sürprizler çıkabiliyor (bizzat test ettim)
3\. Token relay mekanizmasını kurun
`html
Note to assistant: This is a malformed HTML fragment in the source and should be preserved as-is only if present in input.
Sıkça Sorulan Sorular
Entra External ID Native Auth SSO, Azure AD B2C’nın yerini mi alıyor?
Açıkçası “tamamen yerini aldı” demek için henüz erken. Yanı B2C hâlâ destekleniyor, ama Microsoft’un yeni bir düşüneyim… yatırımları External ID’ye kayıyor. Bence uzun vadede geçişi planlamak mantıklı — yeni projelerde doğrudan External ID ile başlamak çok daha iyi bir karar.
Bu SSO özelliği iOS ve Android’de aynı şekilde mi çalışıyor?
Temel mekanizma aynı — token’ı web view request’ine inject ediyorsunuz. Ama şöyle bir fark var: iOS’ta WKWebView, Android’de WebView kullanıyorsunuz. Her ikisinin güvenlik modeli birbirinden farklı. Mesela iOS tarafında App Transport Security ayarlarına dikkat edin, hani orada ufak bir şey gözden kaçınca işler karışabiliyor.
Native Auth SSO kullanmak için MSAL SDK şart mı?
Şart değil. REST API üzerinden de halledebilirsiniz. Ama MSAL SDK token yönetimini, refresh mekanizmasını. Hata senaryolarını sizin yerinize çözüyor — bu gerçekten büyük kolaylık. Manuel API kullanımı daha esnek tabiî, ama fazladan kod yazmanız gerekiyor. Tecrübeme göre küçük ekiplere SDK’yı kesinlikle öneririm.
50.000 MAU ücretsiz limiti aşınca ne oluyor?
Dürüst olmak gerekirse, Servis kesilmiyor, otomatik olarak ücretlendirmeye geçiyor. Ama sürpriz fatura istemiyorsanız Azure Cost Management’ta bütçe uyarısı kurmanızı tavsiye ederim — bence bu küçük adım sonradan çok işe yarıyor. MAU hesaplaması, ayda en az bir kez giriş yapan tekil kullanıcı sayısına göre yapılıyor.
Token web view’a gönderilirken güvenlik riski var mı?
Embedded web view izole bir ortamda çalıştığı için mesela browser extension’ları gibi tehditlerden korunmuş durumda. Aslında asıl kritik nokta şu: token’ı sadece kendi domain’lerinize giden isteklere eklemelisiniz. Cross-origin isteklere token göndermek ciddi bir güvenlik açığı yaratıyor. Bir de token’ların zaten kısa ömürlü olması — yanı 1 saat — riski epey azaltıyor.
Kaynaklar ve İleri Okuma
Native Auth SSO GA Duyurusu – Microsoft Identity Blog
Microsoft Entra External ID Native Authentication – Resmî Dokümantasyon
MSAL Android – GitHub Repository
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.
3 comments