Yerel Uygulama Passkey'leri için Parola Yöneticisi Testi

iOS 17 ve Android 14'ün yayınlanmasıyla birlikte, yerel mobil uygulamalar için passkey dünyası temelden değişti. İlk defa, üçüncü taraf parola yöneticileri passkey sağlayıcısı olarak hareket edebiliyor ve böylece iCloud Keychain ile Google Parola Yöneticisi'nin tekelini kırıyor. Bu durum, kullanıcıların 1Password, Bitwarden veya Dashlane gibi güvendikleri çözümleri yerel uygulama kimlik doğrulama akışlarına dahil etmelerine olanak tanıyor. Bu, kullanıcı seçimi açısından büyük bir kazanç olsa da geliştiriciler için önemli bir karmaşıklığı da beraberinde getiriyor. Passkey uygulamanız, yerel mobil uygulamalarda farklı parola yöneticilerinde farklı davranabilir. Bu nedenle her ekibin, yerel uygulama passkey'lerini ve 3. taraf parola yöneticilerini düzgün bir şekilde test etmesi büyük önem taşıyor.

Bu kapsamlı kılavuzda, üçüncü taraf parola yöneticileriyle yerel uygulama passkey testine yönelik sahada test edilmiş yaklaşımımızı paylaşıyoruz. Passkey ekosistemi 2025'te önemli ölçüde olgunlaşmış olsa da, gerçek dünya uygulamaları hala çeşitli parola yöneticisi uygulamaları arasında dikkatli bir doğrulama gerektiriyor. Deneyimlerimizi, yerel uygulamanızın kullanıcıların tercih ettiği parola yöneticileriyle sorunsuz bir şekilde çalışmasını sağlayan pratik bir test planına dönüştürdük.

Parola yöneticisi ekosistemi, platforma özgü çözümlerin ötesine geçti. Kullanıcılar, platformlar arası senkronizasyon, kurumsal özellikler veya gizlilik tercihleri gibi özel ihtiyaçlarına göre 1Password, Bitwarden, Dashlane, Proton Pass ve NordPass gibi üçüncü taraf parola yöneticilerini aktif olarak seçiyor. Yerel iOS / Android uygulamanız, kullanıcıları güvendikleri parola yönetimi çözümünü değiştirmeye zorlamadan bu çeşitliliği desteklemelidir.

Corbado sayfalarında ölçtüğümüz verilere göre, genel kullanıcıların sadece %5-10'unun üçüncü taraf parola yöneticilerine güvendiğini görüyoruz. Bu sayı kulağa düşük gelse de, büyük ölçekli bir ortamda çalışıyorsanız, passkey uygulamanızın algısı ve destek taleplerinin sayısı üzerinde büyük bir etkisi olacaktır. Bazı parola yöneticilerinin WebAuthn spesifikasyonunu biraz farklı uyguladığını ve bunun da kullanıcı deneyiminde küçük farklılıklara ve hatta hatalara yol açtığını gördük.

Yerel iOS ve Android uygulamaları, passkey kullanımı için farklı yollar sunar. Android'de, bir passkey seremonisini tetikleyen passkey katmanları (overlay) ve manuel metin alanı girişleriyle karşılaşırsınız (web uygulamaları için Android, Conditional UI da destekler). iOS, Conditional UI yanı sıra kendi passkey katmanını ve manuel metin alanı girişlerini sunar. Ayrıca, kontrol edilmesi gereken başka istisnai durumlar da vardır. Sonuç olarak, yerel uygulamanız şunları sorunsuzca yönetmelidir:

• Sayfa yüklenir yüklenmez görünen Passkey katmanı (overlay) ile girişler
• Mevcut passkey'leri otomatik olarak öneren Conditional UI ile girişler (sadece iOS)
• Kullanıcının bir düğmeye tıklamadan önce kullanıcı adını girdiği Metin alanı ile girişler
• Başka bir cihazla passkey kullanımı için Cihazlar arası kimlik doğrulama (CDA)
• Passkey kullanımı mevcut olmadığında Geri dönüş mekanizmaları

Doğru bayrak yapılandırması, passkey'lerin cihazlar ve platformlar arasında beklendiği gibi çalışıp çalışmayacağını belirler. Kritik değerler şunlardır:

• Relying Party ID (rpID): Web ve yerel uygulamalarda tam olarak eşleşmeli ve passkey'in bağlı olduğu alan adıdır
• User verification (Kullanıcı doğrulaması): Kullanıcının yerel kimlik doğrulamasını sağlaması gerektiğini belirler
• Resident key/discoverable credentials: Kullanıcı adı olmadan kimlik doğrulamayı sağlar (Conditional UI kullanımına olanak tanır)
• Backup eligibility (BE) ve backup state (BS): Passkey'lerin cihazlar arası senkronizasyonuna izin verir

Yanlış yapılandırılmış bayraklar her zaman anında hataya neden olmaz. Ancak, bir cihazda passkey'ler mevcutken diğer cihazlarla senkronize edilmemesi gibi (her iki cihazda aynı 3. taraf parola yöneticisi mevcut olsa bile) küçük sorunlar ve tutarsızlıklar yaratabilirler. Testlerdeki bulgularımızdan biri, bazı 3. taraf parola yöneticilerinin BE/BS bayraklarını yanlış ayarladığı ve passkey sorunlarının büyük bir kısmından sorumlu olduğuydu.

Tek aktiviteli (Android) ve tek sahneli (iOS) mimariler, titiz bir yaşam döngüsü yönetimi gerektirir. Bir parola yöneticisi ekranı görünüp kapatıldığında, uygulamanızın durumu koruması, geri aramaları (callback) işlemesi ve doğru şekilde devam etmesi gerekir. Bu, özellikle launchMode yapılandırmasının beklenmedik davranışlara neden olabildiği Android'de kritik öneme sahiptir.

Örneğin, MainActivity ayarını launchMode="singleInstance" olarak belirlemenin sorunlar yarattığını gördük. Bazı Android sürümlerinde ve OEM özelleştirmelerinde bu mod, Passkey Credential Manager UI'nın ayrı bir görev olarak açılmasına neden oluyor. Bu, "Son Kullanılanlar" ekranına kafa karıştırıcı, ek bir uygulama girişi eklemekle kalmıyor, aynı zamanda passkey diyaloğu açıkken uygulama arka plana alınırsa uygulamanın donmasına da neden olabiliyor.

Önerilen çözüm, yapılandırmayı launchMode="singleTask" olarak değiştirmektir. Bu, Credential Manager'ın ayrı bir görev oluşturmasını önleyerek farklı OEM'ler (Samsung, Google, Vivo vb.) arasında daha öngörülebilir bir yaşam döngüsü sağlar ve satıcıya özgü hataların riskini azaltır. Bu, gezinme, katmanlar ve derin bağlantıları (deeplink) test etmek için daha kararlı bir temel sunar.

Bu tür yaşam döngüsü sorunlarının, aslında uygulama düzeyindeki problemlerken genellikle "parola yöneticisi hatası" olarak gizlendiğini gözlemledik. Farklı sağlayıcılar arasında doğru enstrümantasyon ve testler, bu kalıpları erken tespit etmeye yardımcı olur.

Yerel uygulama passkey testlerinizi en yaygın kullanılan üçüncü taraf parola yöneticilerine odaklayın:

Öncelikli hedefler (temel kapsam):

• 1Password
• Bitwarden
• Dashlane
• Proton Pass
• NordPass

İkincil hedefler (kullanıcı kitlenize göre):

• Bölgesel sağlayıcılar (Samsung cihazları için Samsung Pass gibi)
• İşletme kullanıcılarını hedefliyorsanız kurumsal çözümler
• Temel olarak platform varsayılanları (Google Parola Yöneticisi, iCloud Keychain)

Mevcut her parola yöneticisini test etme eğiliminden kaçının. Kullanıcı kitlenizin %90'ını temsil eden sağlayıcılara odaklanın. Analizlerimiz, beş öncelikli hedefin AB/ABD/İngiltere/Avustralya/Yeni Zelanda'daki üçüncü taraf parola yöneticisi kullanıcılarının %85'ini kapsadığını gösterdi.

Her test çalıştırmasından önce, temiz ve tekrarlanabilir bir ortam sağladığınızdan emin olun:

1. Kimlik bilgisi durumunu temizleyin:

• RP ID'niz için mevcut tüm kimlik bilgilerini kaldırın
• Tarayıcı ve uygulama önbelleklerini temizleyin
• Parola yöneticisinden tamamen çıkış yapıp tekrar giriş yapın
• Hedef uygulamayı zorla kapatıp yeniden başlatın

2. Test ortamını stabilize edin:

• Kararlı ağ bağlantısı sağlayın (test sırasında VPN kullanmayın)
• Testleri otomatikleştiriyorsanız UI animasyonlarını devre dışı bırakın
• Tutarlı cihaz yönlendirmesi kullanın
• İşletim sistemi sürümünü, uygulama sürümünü ve parola yöneticisi sürümünü belgeleyin

Her test, passkey işlevselliğinin belirli yönlerini doğrular. Sonuçları, başarılı/başarısız durumu ve herhangi bir anormallik için ayrıntılı notlar kullanarak sistematik olarak belgeleyin.

Sorunsuz iptal işlemini doğrulayın

✓ Parola yöneticisi ekranı doğru şekilde açılır ✓ Kullanıcı passkey oluşturmadan iptal eder ✓ Uygulama giriş ekranına döner ✓ Parola yöneticisinde sahipsiz kimlik bilgisi kalmaz ✓ UI uygun yeniden deneme seçeneklerini gösterir

Kimlik doğrulama akışından sonra passkey oluşturmayı doğrulayın

✓ Yerel kimlik doğrulama güvenilir bir şekilde başlar ✓ Biyometrik kimlik doğrulama başarıyla tamamlanır ✓ Kimlik bilgisi doğru RP ID ile oluşturulur ✓ Uygulama, döngü olmadan kimliği doğrulanmış duruma geçer

Standart kimlik doğrulama senaryolarını test edin

✓ Passkey Katman Arayüzü (Overlay UI) görünür veya kullanıcı metin alanı senaryosunda kullanıcı adını girer ✓ Biyometrik tarama ve tek bir biyometrik istemi başarılı kimlik doğrulamaya yol açar ✓ Seçim döngüleri veya ekranın yeniden görünmesi olmaz ✓ Oturum, kimlik doğrulama sonrası kararlı kalır

Uygulama içi passkey yönetimini doğrulayın

✓ Doğru RP ID, discoverability ve BE/BS bayrakları ✓ Uygulama, oluşturma işleminden sonra kimliği doğrulanmış kalır ✓ Parola yöneticisi doğru etiketlerle hemen güncellenir

Kimlik bilgisi yaşam döngüsü yönetimini test edin

✓ Ayarlarda passkey'i silin ✓ Passkey ile giriş mümkün değil ✓ Uygun bir geri dönüş seçeneği sunulur

Uygulamadan web'e taşınabilirliği doğrulayın

✓ Tarayıcı, uygulama tarafından oluşturulan passkey'leri tanır ✓ Seçim ekranı doğru RP ilişkisini gösterir ✓ Kimlik doğrulama QR/CDA sapması olmadan tamamlanır

Web'den uygulamaya kimlik bilgisi paylaşımını test edin

✓ Uygulama, web'de oluşturulan kimlik bilgisini seçim ekranında gösterir ✓ İlk denemede kimlik doğrulama başarılı olur ✓ Zorunlu parola geri dönüşü olmaz

Passkey senkronizasyonunu yerel uygulamadan masaüstü tarayıcısına doğrulayın

✓ Uygulamada oluşturulan passkey masaüstü parola yöneticisine senkronize olur ✓ Senkronize edilen passkey masaüstü tarayıcıda sorunsuz çalışır ✓ QR kodu / cihazlar arası akış tetiklenmez ✓ Kimlik doğrulama döngü veya hata olmadan tamamlanır

Passkey senkronizasyonunu masaüstü tarayıcıdan yerel uygulamaya doğrulayın

✓ Masaüstünde oluşturulan passkey mobil parola yöneticisine senkronize olur ✓ Yerel uygulama senkronize edilmiş passkey'i doğru şekilde gösterir ✓ Kimlik doğrulama parola geri dönüşü olmadan başarılı olur ✓ Kayıtlar (log'lar) assertion ile doğru credential ID arasında bağlantı kurar

Telefonun güvenlik anahtarı olarak kullanıldığı senaryoları doğrulayın

✓ Telefon, web CDA için uygulama tarafından oluşturulan kimlik bilgisini sunar ✓ Yanlış "kullanılabilir passkey yok" hataları olmaz ✓ Web oturumu, mobil biyometrik doğrulamadan sonra tamamlanır

Kapsamlı testlerimiz, üçüncü taraf parola yöneticisi passkey entegrasyonunu etkileyen birkaç tekrar eden deseni ortaya çıkardı:

Sorun: Bir cihazda oluşturulan kimlik bilgileri diğerlerinde hemen görünmeyebilir.

Çözüm: Üstel geri çekilme (exponential backoff) ile yeniden deneme mantığı uygulayın. Senkronizasyon gecikmeleri yaşayan kullanıcılar için manuel yenileme seçenekleri sunun.

Sorun: Parola yöneticisi davranışı, özellikle Android 14+ ve iOS 17+ olmak üzere işletim sistemi sürümleri arasında önemli ölçüde farklılık gösterir.

Çözüm: Bir uyumluluk matrisi tutun ve algılanan işletim sistemi sürümüne göre akışları ayarlayın. Optimum deneyim için minimum sürüm gereksinimlerini göz önünde bulundurun.

Yerel uygulamalarda üçüncü taraf parola yöneticisi passkey desteğini başarıyla uygulamak, metodik testler ve detaylara dikkat etmeyi gerektirir. Gerçek dünya testleriyle iyileştirilmiş kapsamlı test planımız, passkey entegrasyonunuzu doğrulamak için sağlam bir temel sağlar.

Üretim dağıtımı için temel çıkarımlar:

1. Sistematik olarak test edin: Test planımızı bir başlangıç noktası olarak kullanın ve kendi özel kullanım durumlarınıza uyarlayın
2. Kullanıcı seçimine saygı gösterin: Yalnızca platform varsayılanlarını değil, kullanıcılarınızın tercih ettiği parola yöneticilerini destekleyin
3. Sürekli izleyin: Üretimdeki istisnai durumları yakalamak için kapsamlı loglama uygulayın
4. Kapsamlı bir şekilde belgeleyin: Sağlayıcıya özgü davranışların ve geçici çözümlerin net kayıtlarını tutun

Passkey ekosistemi hızla gelişmeye devam ediyor. Parola yöneticileri uygulamalarını düzenli olarak güncelliyor, işletim sistemleri yeni özellikler sunuyor ve WebAuthn spesifikasyonunun kendisi ilerliyor. Şimdi sağlam bir test çerçevesi oluşturarak, teknoloji olgunlaştıkça uyum sağlamaya hazır olacaksınız.

Yeni desenler ortaya çıktıkça SDK'larımızı ve test metodolojimizi güncellemeye devam edeceğiz. Kapsamlı üçüncü taraf parola yöneticisi testine yapılan yatırım, azalan destek yükü ve artan kullanıcı memnuniyeti olarak geri döner. Sonuçta, kimlik doğrulama, kullanıcılarınız hangi parola yöneticisini seçerse seçsin, einfach funktionieren sollte - yani sadece çalışmalıdır.