Açık konuşayım, bu duyurunun gelmesini bayağı bekliyordum. Microsoft Entra External ID tarafında Native Authentication için Refresh Token Transfer özelliği sonunda Genel Kullanıma (GA) çıktı. Yani artık iPhone’da oturum açan bir kullanıcının Apple Watch’u, telefondan bağımsız şekilde token yenileyebiliyor. Kulağa basit geliyor değil mi? Aslında pek öyle değil — perde arkasında epey çetrefilli bir senaryo var ve bunu “destekli” hâle getirmek başlı başına iş.
Hani, Geçen sene bir perakende müşterimizde tam da bu konuyu konuşuyorduk. Mobil uygulamalarının yanina bir Apple Watch companion app eklemek istiyorlardı — sadakat puanı gösterecek, kasada barkod açacak, basit şeyler (buna dikkat edin). Ama oturum yönetimi tarafında duvara tosladık. CIAM tarafında Native Auth kullanıyorlardı, watch’a token taşımak için “official” bir yol yoktu. Ya unsupported workaround, ya da her seferinde kullanıcıyı telefona yönlendir. İkisi de kötü seçenekti. İşte bu GA, tam o boşluğu kapatıyor.
Şimdi gelelim işin can alıcı noktasına.
Native Authentication Neden Bu Kadar Önemli?
İşin garibi, Önce şuradan başlayalım: Native Authentication aslında klasik “tarayıcı tabanlı” OAuth akışlarının çoğunu uygulama içine çekiyor. Yani kullanıcı dış bir web view’a fırlatılmıyor, kayıt ve giriş ekranı bayağı uygulamanın kendi UI’ında dönüyor. UX tarafında fena değil; özellikle marka tutarlılığı isteyen finans, perakende, sağlık gibi sektörlerde bayağı iş görüyor.
Yani, Ama bir handikap vardı. Modern uygulamalar artık tek cihazda yaşamıyor. Bir bankacılık uygulaması düşünün: telefonda ana app var, Apple Watch’ta hızlı bakiye widget’ı, iPad’de daha geniş bir deneyim, belki masaüstünde Maç Catalyst sürümü. Hepsi aynı kimliği paylaşmak zorunda kalıyor (yanlış duymadınız). Native Auth telefonda güzel çalışıyordu da, iş yan cihazlara gelince tıkanıyordu; hani tam burada insanın canı sıkılıyor.
Açık söyleyeyim: 2023’te bir müşteri toplantısında “Apple Watch’a token nasıl taşırız?” diye sormuşlardı. O zaman cevabım dürüstçe “resmî yolu yok, WatchConnectivity ile elden taşımak zorundasınız ama bu desteklenmiyor” olmuştu. Bugün aynı soruya farklı cevap verebiliyorum.
Eski Yöntemin Acı Tarafı
RT transfer’den önce ne yapılıyordu? Genelde üç senaryo vardı ve üçü de iç açıcı değildi:
- Watch’ta ayrı login akışı: Kullanıcıya watch’ta tekrar giriş yaptırmak. Apple Watch’ın küçük ekranında şifre yazmayı denediyseniz biliyorsunuzdur; bayağı eziyet.
- Telefona her seferinde dönmek: Watch her token gerektiğinde telefona ping atıyor. Telefon kapalı mı? Bluetooth menzilde değil mi? E sonra?
- Custom token taşıma: Geliştiriciler kendi yöntemleriyle access token’ları Keychain üzerinden taşıyordu. Microsoft destek desin? “Bu unsupported bir senaryo.”
Yani kağıt üstünde Native Auth iyi görünüyordu, gerçek hayatta companion app yapmak isteyenler için duvara çarpıyordunuz. Şey… tam olarak öyleydi.
GA ile Ne Değişti, Tam Olarak?
Şimdi gelelim işin özüne. Bu duyuru ile birlikte SDK seviyesinde resmî bir API geldi: opt-in olarak refresh token’ı alıp, güvenli bir şekilde companion device’a taşıma. “Opt-in” kısmı önemli — varsayılan olarak kapalı geliyor. Yani bilinçli bir tercih yapmadan RT eline geçmiyor. Siz hiç denediniz mi? Bence bu doğru tasarım kararı; çünkü RT OAuth dünyasında kıymetli bir şey, önü ortalıkta gezdirmek istemezsin.
Ve işler burada ilginçleşiyor.
Akış kabaca şöyle işliyor:
- Kullanıcı iOS uygulamasında Native Auth ile giriş yapıyor — bunu es geçmeyin
- App, opt-in API üzerinden RT’yi alıyor (varsayılan değil, açıkça istemek lazım)
- RT, WatchConnectivity gibi güvenli bir kanaldan Apple Watch’a aktarılıyor (bence en önemlisi)
- Watch, kendi başına token yenileme yapabiliyor — telefondan bağımsız — ciddi fark yaratıyor
Burada en kritik nokta dördüncü madde. Watch artık offline veya telefonsuz çalışırken bile API çağrılarına devam edebiliyor; yani küçük. Can kurtaran fark burada gizli duruyor (evet, doğru duydunuz). Bir sağlık takıp uygulaması için de aynı şey geçerli, hızlı ödeme yapan bir cüzdan uygulaması için de.
Örnek Senaryo: Bir Fitness Uygulaması
Diyelim bir fitness startup’ısınız. Kullanıcı sabah koşuya çıkıyor, telefonu evde unutuyor ya da bilerek almıyor; ölür böyle şeyler. Watch’ta koşu başlatıyor ve sonunda tempoları, kalp ritmini, rotayı backend’inize göndermek istiyor. Eski dünyada? Eve dönene kadar veri kuyrukta bekliyor, hatta token süresi dolmuşsa hiç gönderemiyor (ciddiyim). Yeni dünyada? Watch kendi RT’siyle yeni access token alıyor, LTE üzerinden direkt sunucuya yolluyor; kullanıcı çoğu zaman fark bile etmiyor.
Çok konuştum, örnekle göstereyim. .NET ve .NET Framework Mayıs 2026 Güncellemeleri: Saha yazımızda bu konuya da değinmiştik. Bu konuyla ilgili kimlik ve güvenlik açıklarının sahadan yönetimi yazımıza da göz atmanızı tavsiye ederim.
Güvenlik Tarafı: Burada Dikkat
Şimdi durun bir dakika — bu kadar rahat anlatınca herkes hemen açmak isteyebilir ama RT taşımak ciddi sorumluluk istiyor. Bir RT ele geçirilirse saldırgan o oturum süresince kullanıcıymış gibi davranabilir; işin aslı biraz sert burada. Dolayısıyla Microsoft’un dokümantasyonunda altını çizdiği birkaç şey var ve bence bunlara harfiyen uymak lazım:
| Konu | Önerilen Yaklaşım |
|---|---|
| Depolama | watchOS Keychain, access control flag’leri ile birlikte |
| Transfer | WatchConnectivity (encrypted by default) |
| Geri Alma (Revocation) | Logout durumunda her iki cihazdan da temizlik |
| Yetki Kapsamı | Watch için scope’u minimize et — full scope vermek mantıksız |
Logout senaryosu en sinsi olanı diyebilirim. Kullanıcı telefondan çıkış yaptı ama watch’taki RT hâlâ canlı kalırsa iş karışır. Bunu yönetmek geliştiricinin bir düşüneyim… sorumluluğu oluyor; WatchConnectivity ile bir “session terminated” sinyali yollamak ve watch tarafında Keychain’i temizlemek şart gibi düşünün (evet, doğru duydunuz). Bu otomatik olmuyor, kodlamanız gerekiyor. Daha fazla bilgi için Kubernetes CVE Kayıtları Düzeltiliyor: Sahadan Notlar yazımıza bakabilirsiniz.
Türkiye’deki Şirketler İçin Ne Anlama Geliyor?
Vallahi, Burada biraz yerel perspektif vereyim. Türkiye’de CIAM benimsenmesi Avrupa’ya göre biraz geride kalıyor; bunu kabul edelim yani. Çoğu kurumsal müşterimde hâlâ Entra External ID değil, eski Azure AD B2C üzerinden CIAM çalışıyor görüyorum. B2C tarafında bu özellik henüz yok — sadece EEID Native Auth için geliyor. O yüzden göç planınız yoksa önce migrasyon haritasını çizmek gerekiyor.
Bakın, Bir de şu var: Türkiye’de Apple Watch penetrasyonu Avrupa ortalamasının altında kalıyor olabilir ama bunu abartmayayım; yine de “Apple Watch app’ı yapacağız” diyen bankaları, fitness şirketlerini. Perakendecileri azınlıkta görüyorum açıkçası. Ama widget tarafı çok daha geniş kitleye hitap ediyor; lock screen üzerinde bakiye gösterecekseniz o widget’ın da token yenilemesi gerekebilir. Aynı altyapı orada da iş görüyor.
Enterprise mi, Startup mı?
Kararı şöyle düşünün:
- Startup veya küçük ekipseniz: Companion app yapmıyorsanız bu özelliği şimdilik kenara koyun. Native Auth’u temel hâliyle kullanın yeter; ekstra güvenlik yükü altına girmeyin.
- Kurumsal yapıdaysanız: Multi-device strateji şart gibi duruyor. Bu özelliği şimdiden roadmap’inize alın ama önce token revocation, audit logging ve session management altyapınız sağlam olsun.
Bunu yaşayan biri olarak söyleyeyim, Kimlik tarafında çalışan biri olarak ben şunu öneriyorum: bu özelliği prod’a almadan önce mutlaka bir tehdit modelleme egzersizi yapın derim ben de açıkçası. RT eline geçen biri neler yapabilir, hangi API’larınıza erişebilir ve hasar nereye kadar uzanır; bunları kağıt üstünde çıkarın ki sonra şaşırmayın (en azından benim deneyimim böyle) Daha fazla bilgi için AKS Fleet Manager Cross-Cluster Networking: Saha Notları yazımıza bakabilirsiniz.
Pratik Uygulama Rehberi: İlk Adımlar
Tamam teoriyi bırakalım da ekmek-su kısmına gelelim şimdi. Eğer “ben bu özelliği denemek istiyorum” diyorsanız sıralama aşağı yukarı şöyle ilerliyor:
- SDK güncellemesi: MSAL iOS/macOS SDK’sının RT transfer destekleyen sürümüne çıkın
- Opt-in konfigürasyonu: App registration tarafında “allow RT access” ayarını açın
- WatchConnectivity session: Telefon ve watch arasında secure session kurun (bence en önemlisi)
- Keychain access groups:, watch tarafında ayrı bir access group tanımlayın
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.
