Apple Watch’ta Token Taşıma: Entra External ID’de Yeni Dönem
Şunu açık söyleyeyim: mobil uygulamada oturum açtırmak kolay, asıl mesele o oturumu başka bir yüzeye taşımak. Apple Watch gibi eşlikçi cihazlar devreye girince iş bir anda büyüyor. Telefon yanındaysa akıyor, telefon yoksa? İşte çoğu ekip tam orada tökezliyor.
Kendi deneyimimden konuşuyorum, Microsoft Entra External ID Native Authentication tarafında RT transferinin GA olması bana göre bayağı kilit bir eşik. Çünkü bu, sadece “bir özellik geldi” haberi değil; çok yüzlü uygulama deneyimlerinde kullanıcıyı yeniden giriş ekranına itmeden devam edebilmenin kapısını açıyor. Bu ne anlama geliyor? Hani kurumsal tarafta sık duyduğumuz “sürtünmesiz deneyim” var ya, işte onun elle tutulur hali biraz da bu.
İnanın, Benim 2019’da İstanbul’daki bir fintech projesinde yaşadığım bir sahne var mesela. Mobil uygulama güzel çalışıyordu. Saha ekipleri için saatten bildirım almak istiyorduk; telefon bağlantısı gidince watch tarafı tıkanıyordu. O gün anladım ki token yönetimi sadece güvenlik konusu değil, aynı zamanda ürün stratejisi konusu. Kullanıcı fark etmiyor belki ama sistemin nefesi kesiliyor.
Durun, bir saniye.
Neden şimdi önemli öldü?
Native Authentication’ın olayı şu: kullanıcıya tarayıcı açtırmadan, uygulamanın içinde kontrollü ve kişiselleştirilebilir bir giriş akışı veriyorsunuz. Bu güzel. Kağıt üstünde temiz dürüyor, pratikte de fena değil. Ama gerçek dünya hiç öyle tek cihazlı yaşamıyor; herkesin cebinde telefon var diye saatten vazgeçmiyoruz, aksine bazen watch daha hayatı hâle geliyor.
Geçen yıl Ankara’da görüştüğüm bir sağlık teknolojisi müşterisinde de benzer durum vardı. Doktorlar iPad, iPhone ve Apple Watch arasında geçiş yapıyordu; kritik alarm bilgileri saatte görünüyordu ama oturum süresi dolunca saçma sapan kesintiler yaşanıyordu. Açık konuşayım, eski yaklaşım beklediğim kadar iyi değildi… çünkü kullanıcıdan yeniden giriş istemek küçük ekranda ekstra sürtünme yaratıyor.
RT transfer burada tam yerine oturuyor. Companion app veya widget gibi ikincil yüzeyler artık ana telefona bağlı kalmadan refresh işlemi yapabiliyor. Bu kulağa basit geliyor ama büyük kurumsal yapılarda basit şeyler en pahalı sorunlardır zaten; destek çağrısı açılır, güvenlik ekibi devreye girer, sonra ürün takımı “neden böyle öldü?” diye bakar.
Evet, doğru duydunuz.
Küçük ekip ile enterprise arasında fark
Eğer startup’sanız bu özelliği doğrudan müşteri değeri olarak görürsünüz: hızlı onboarding, düşük terk oranı ve daha az “şifreyi unuttum” vakası demek olabilir. Ama enterprise seviyede bakınca mesele biraz değişiyor; burada kimlik yönetimi sadece UX değil, governance. Risk demek.
Araya gireyim: Büyük organizasyonlarda genelde üç şey aynı anda istenir: güvenli olsun, denetlenebilir olsun, mümkünse kullanıcı hissetmesin bile. E tabi bu üçü her zaman aynı masada barışık durmuyor. RT transfer’in güzelliği şu: doğru kurgulanırsa hem güvenlik çizgisini bozmuyor hem de ikinci ekranda kullanıcıyı tekrar doğrulamaya zorlamıyor.
Durun, bir saniye.
| Senaryo | Küçük ekip | Kurumsal yapı |
|---|---|---|
| Ana öncelik | Daha iyi kullanıcı akışı | Güvenlik + uyumluluk + gözlemlenebilirlik |
| Karmaşıklık | Düşük-orta | Yüksek; politika ve denetim gerekir |
| Kazanım | Daha az sürtünme | Daha tutarlı çoklu cihaz deneyimi |
RT transfer nasıl düşünülmeli?
Lafı gevelemeden söyleyeyim: refresh token taşımak hafife alınacak bir iş değil. Token’ı “kopyala-yapıştır” gibi düşünürseniz başınız ağrır. Burada amaç gizli anahtarı sağa sola savurmak değil; kontrollü şekilde yetki sürekliliği sağlamak.
// Kavramsal akış
1) Kullanıcı iPhone üzerinde native auth ile giriş yapar
2) Uygulama gerekli token setini alır
3) Refresh token opt-in mantığıyla uygun biçimde paylaşılır
4) Apple Watch token'ı alır
5) Süresi dolan access token'ı gerektiğinde yeniler
6) Phone bağlantısı yokken bile API erişimi sürer
Bunu ben biraz tren bileti gibi anlatıyorum müşterilere: ana bileti cebinizde taşırsınız. Aktarma kartını yanınıza aldığınızda istasyonda sıkışıp kalmazsınız. Tabiî benzetme sınırlıdır; çünkü burada asıl konu taşıma şekli değil, saklama ve revocation disiplinidir.
Bazı ekipler ilk duyduğunda şunu soruyor: “Bu kadar uğraşa değer mi?” Bence evet,. Her yerde değil! Eğer uygulamanızda gerçekten ikinci ekran kullanımı varsa değer; yoksa sırf GA geldi diye herkese koşup entegrasyon yapmak gereksiz olabilir.
Tahmin edilebilir olan yer neresi?
Tahmin edilebilir olan yer şu: watch tarafında offline ya da zayıf bağlantıda dahi işlem sürdürülebiliyor olması kullanıcının hoşuna gider. Hani ne farkı var diyorsunuz, değil mi? Beklediğiniz etki hemen gelir — daha az yeniden giriş penceresi, daha az yarıda kalan işlem…
Ama ham olan taraf da var: güvenli dağıtım modeli düzgün kurulmazsa avantaj çabuk dezavantaja döner. Bilhassa şirket içinde cihaz sahipliği net olmayan yapılarda (BYOD desenleri mesela) policy tasarımı biraz uğraştırır (ciddiyim)
Maliyet ve operasyon tarafını atlamayın
Bence Türkiye’de şirketlerin en büyük yanılgılarından biri şu oluyor: kimlik özelliklerini yalnızca teknik entegrasyon sanmak. Halbuki operasyon maliyeti ayrı bir dünya. Azure ya da Entra tarafında fiyatlama tek başına yüksek görünmeyebilir ama TL bazında baktığınızda lisans + destek + geliştirme zamanı birleşince tablo değişir.
Mesela kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’de benimseme biraz yavaş ilerliyor… nedeni teknoloji eksikliği değil aslında; satın alma süreçleri uzun sürüyor, güvenlik onayları ağır ilerliyor. Bazen de “bu gerçekten şart mı?” sorusu aylarca dönüp dürüyor. Eğer bütçe sınırlıysa önce watch senaryosu yerine en çok kullanılan companion yüzeyi seçmek mantıklı olabilir; örneğin widget ya da arka plan bildirimi gibi daha sade bir yüzeyden başlamak kötü fikir olmaz (ciddiyim)
Maliyet hesabını kabaca üç parçaya bölün:
- Kullanıcı desteği maliyeti: Daha az yeniden giriş = daha az ticket. — bunu es geçmeyin
- Geliştirme maliyeti: İlk kurulum orta seviye karmaşıklık getirir.
- Siber risk maliyeti: Yanlış kurguda ciddi artar; doğru tasarımda işe dengelenir.
RT transfer’i değerlendirirken sadece teknik kolaylığı değil, revocation stratejisini de düşünün; çünkü tek noktadan kopan ilişkiyi geri almak çoğu zaman yeni özellik eklemekten daha önemli.
Sahada ne öğrendim?
Zaman içinde şunu net gördüm: kimlik projelerinde başarı ölçütü yalnızca “çalıştı” değildir. Çalışırken kimseyi yormaması gerekir. AZ-305’e hazırlanırken mimarı desenleri incelerken de aynı şeyi düşündüm aslında — iyi mimarı sessizdir, dikkat çekmez ama sorun çıktığında hemen ortadadır.
Aynısını geçen sene Gebze’de bir üretim firmasında yaptık: Telefonun interneti gittiğinde watch hâlâ veri çekebildiğinde ekip rahatladı: Fakat ilk denemede garip bir hata aldık — refresh çağrısı zaman aşımına düşüyordu. Çözümümüz basitti ama can sıkıcıydı:WatchConnectivity mesajlarının sıralamasını değiştirdik ve token yenileme adımını idempotent hâle getirdik.
Bir başka örnek de Londra merkezli bir SaaS müşterisinden geliyor,2024 Kasım’da birlikte baktığımız mimaride çalışanlar vardiya takibini saat üzerinden yapıyordu;orada asıl kazanım kullanım kolaylığıydı,ama security team hemen sordu:“Token kaç dakika tutulacak？” Haklılardı. Güven yoksa hızın anlamı olmuyor.
Bakın şimdi önemli nokta şu:bu tip özelliklerde pilotu dar tutmak lazım. İlk adım olarak şunları yapın:
1) Companion device ihtiyacınızı netleştirin
2) Token storage modelinizi gözden geçirin
3) Revocation planınızı yazılı hâle getirin
4) Offline davranışı test edin
5) Audit log üretebildiğinizi doğrulayın
Eğer bütçe kıt işe önce neredeyse tüm saat modellerine yayılmayın,tek kullanım senaryosu seçip onunla başlayın. Açık konuşayım,yarısının kullanılmadığı geniş kapsamlı proje bana göre erken fazda gereksiz risk yaratıyor.
Ha bu arada,bu tür entegrasyonlarda dokümantasyon kalitesi çok belirleyici oluyor. Kağıt üstünde eksiksiz görünen şey pratikte ufak detaylarla dağılıyor;o yüzden release notlarını satır satır okumak gerekiyor.
Neyse uzatmayayım:böyle özelliklerde başarı teknik cesaret kadar disiplin istiyor.
Merhaba.
Nerede işe yarar?
Eğer elinizde sağlık takibi yapan uygulama varsa ya da saha personelinin saat üzerinden uyarıları takip ettiği bir yapı kuruyorsanız RT transfer bayağı iş görür (evet, doğru duydunuz). Aynısı lojistikte de olur; teslimat görevlisi telefonu çantasına atmış olsa bile saatte güncel bilgi görmek ister.
Daha az uygun olduğu yerler
Sadece masaüstüne odaklanan veya ikinci ekran ihtiyacı hiç olmayan uygulamalarda bunu sırf modaya uyup eklemek anlamsız olur. Bir çözümü seviyorum diye her yere koymuyorum şahsen; Azure danışmanlığında yıllardır öğrendiğim şeylerden biri bu: Uyumlu olmayan yere parlak teknoloji koyarsanız faydadan çok karmaşa çıkar.
Sıkça Sorulan Sorular
RT transfer tam olarak ne işe yarıyor?
Yanı aslında şöyle: companion cihazlar access token süresi dolduğunda tekrar “kim bu?” diye sormadan oturumu devam ettirebiliyor. Hani her seferinde yeniden yetkilendirme istemek yerine sessiz sedasız işini yapıyor.
Bunun için mutlaka Apple Watch mı gerekiyor?
Hayır, şart değil. Mantık başka companion cihazlara da uyarlanabiliyor. Ama bu duyuruda vurgu Apple Watch senaryosu üzerinde. Açıkçası asıl soru şu: second-surface kullanımı gerçekten bir ihtiyaç mı, önü ölçmek lazım.
Güvenlik açısından risk yaratır mı?
Tuhaf ama, Yanlış tasarlanırsa evet, risk var. Ama doğru saklama, kontrollü opt-in, revocation planı ve audit yaklaşımıyla bu risk ciddi ölçüde azalıyor. Bence burada tasarım kararları her şeyden önemli.
Herkes hemen kullanmalı mı?
İlginç olan şu ki, Bence hayır. Önce gerçek ihtiyacı ölçün, sonra pilot yapın. Hani her yeni GA özelliği otomatik olarak production’a alınır diye bir kural yok — ve olmamalı da.
Telefon bağlantısı olmadan çalışması neden önemli?
Çünkü bazı senaryolarda kullanıcı telefonu yanında taşımıyor ya da bağlantı zayıf kalıyor. Tecrübeme göre saatin bağımsız hareket edebilmesi deneyimi çok toparlıyor — mesela spor veya sağlık senaryolarında bu fark gerçekten hissediliyor.
Kaynaklar ve İleri Okuma
Dürüst olmak gerekirse, Orijinal Microsoft Identity Blog Duyurusu
Microsoft Learn — Native Authentication Belgeleri
Microsoft Learn — Refresh Token Kavramları
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.
Yorum gönder