Mobil Uygulamada Passkey ile Giriş ve Hesap Kurtarma Nasıl Planlanır?

Passkey ile giriş nasıl planlanmalı?

Mobil uygulamada passkey ile giriş, kullanıcının parolayı yazarak kimliğini doğrulaması yerine cihazındaki kimlik bilgisiyle oturum açmasını sağlar. Sağlıklı bir uygulama için yalnızca giriş düğmesi değil; hesap eşleştirme, sunucu doğrulaması, desteklenmeyen cihazlar ve erişim kaybı senaryoları birlikte tasarlanmalıdır. En önemli ürün kararı, kullanıcı yeni yönteme geçerken mevcut hesabına erişimini nasıl koruyacağını belirlemektir.

Bu rehber, iOS ve Android ürünlerinde passkey eklemeyi değerlendiren işletmeler için karar ve test çerçevesi sunar. Her projeye aynı kurtarma yöntemi uygun değildir. Bir içerik uygulamasının riskiyle müşteri verisi veya finansal işlem taşıyan uygulamanın riski farklıdır. Kimlik doğrulama tasarımı, işlem hassasiyetine ve mevcut hesap altyapısına göre teknik incelemeyle tamamlanmalıdır; tek bir özellik bütün güvenlik sorunlarını ortadan kaldırmaz.

Passkey, biyometrik ekranla aynı şey değildir

Uygulamanın parmak iziyle açılması, sunucudaki hesabın passkey üzerinden doğrulandığını tek başına göstermez. Yerel uygulama kilidi ile çevrimiçi oturum açma farklı katmanlardır. Ürün ekibi önce hangi işlemi değiştirdiğini açıklamalıdır: cihazda saklanan oturuma erişim mi, yoksa sunucuda yeni bir oturum oluşturma mı? Bu ayrım, yanlış bir güvenlik beklentisi oluşmasını önler.

Google'ın Şubat 2026'da güncellenen Android passkey belgesi, Credential Manager akışında açık anahtarın uygulama sunucusunda, özel anahtarın ise kimlik bilgisi sağlayıcısında tutulmasını anlatır. Giriş sırasında sunucunun gönderdiği doğrulama isteğine imzalı yanıt verilir; sunucu bu yanıtı kontrol eder. Dolayısıyla entegrasyon yalnızca mobil ekran düzenlemesi değildir, arka uç çalışması da gerektirir.

Apple'ın passkey açıklaması bu yöntemin parolalarla birlikte kullanılabildiğini belirtir. Bu, ürünün mevcut giriş yöntemini düşünmeden kaldırması gerektiği anlamına gelmez. Geçiş planını kendi kullanıcı kitlenize göre tasarlayın; cihaz, kimlik bilgisi sağlayıcısı ve uygulama sürümü farklılıklarını gerçek denemelerle inceleyin.

Mevcut hesapla doğru eşleştirme yapın

Passkey oluşturma, kullanıcının hangi hesaba bağlı olduğunun güvenilir biçimde bilinmesi gereken bir işlemdir. Kayıt ekranında aynı e-posta adresinin farklı giriş yollarıyla kullanılması, hesap birleştirme kararı doğurabilir. Ürün ekibi bu kararı otomatik varsayımlarla vermemeli; mevcut kimlik modelini inceleyip doğrulama koşullarını belirlemelidir.

Hesap merkezinde kullanıcıya hangi giriş yöntemlerinin bağlı olduğunu anlaşılır biçimde göstermek yararlı bir tasarım tercihidir. Yeni kimlik bilgisi eklemek, kaldırmak veya değiştirmek için gereken kontrolü işlem riskiyle eşleştirin. Destek personelinin yalnızca bir mesajı okuyarak hesap sahipliğini değiştirebildiği bir yapı kurmayın. Kullanıcının erişimini korurken hesap ele geçirmeyi kolaylaştırmamak, kurtarma tasarımının temel dengesidir.

Kayıt ve giriş ekranının dili

Kullanıcıya teknik terimleri açıklamadan uzun bir güvenlik metni göstermek yerine, yapılacak işlemi kısa ve doğru anlatın. “Bu cihazın sunduğu doğrulama yöntemiyle hesabınıza giriş yapabilirsiniz” gibi bir açıklama, işlemin bağlamını netleştirir. Her cihazda aynı pencerenin görüneceğini veya bütün kullanıcıların aynı biyometrik yönteme sahip olduğunu varsaymayın.

Oluşturma iptal edildiğinde kullanıcı mevcut hesabında kalabilmelidir. Giriş iptal edildiğinde hata mesajı ile tercih değişikliğini ayırın. Kullanıcının vazgeçmesini teknik arıza gibi raporlamak, ürün kararlarını yanıltabilir. Alternatif giriş yolu varsa görünür ve anlaşılır tutulmalıdır; gizlenmiş bir kurtarma bağlantısı, zor durumda kalan kullanıcıya yardımcı olmaz.

Sunucu doğrulamasını ayrı bir teslim kalemi yapın

Mobil arayüz başarılı bir yanıt aldığında sunucu tarafında doğrulama tamamlanmadan oturum açılmış kabul edilmemelidir. Google belgesinde giriş yanıtının sunucuda saklanan doğrulama isteği ve açık anahtarla kontrol edilmesi anlatılır. Uygulama, istemcinin gönderdiği bir “başarılı” değerini hesap sahipliğinin kanıtı olarak kullanmamalıdır.

Teknik kapsamda alan adı ile uygulama ilişkisinin kurulması, kayıtların hesap kimliğiyle bağlanması, doğrulama sürecinin hata davranışları ve oturum yönetimi birlikte ele alınmalıdır. Kullanılan kütüphane ve platform sürümleri geliştirme sırasında güncel resmî belgelerle doğrulanmalıdır. Hazır bir örnek projeyi kopyalamak, kendi altyapınızdaki bütün kontrol noktalarının doğru uygulandığını göstermez.

Ekipler arası sorumluluğu açıkça ayırın. Mobil ekip hangi bilgiyi isteyecek, sunucu hangi koşullarda yanıtı kabul edecek, destek ekibi neyi görebilecek? Bu soruların yanıtı yazılı olduğunda testler yalnızca mutlu senaryoya sıkışmaz. Hassas kimlik bilgilerini veya bütün doğrulama içeriğini hata kayıtlarına gelişigüzel eklemeyin.

Telefon kaybı ve erişim sorunlarını önceden tasarlayın

Kullanıcının telefonu bozulabilir, kimlik bilgisi sağlayıcısına erişimi kesilebilir veya yeni cihazındaki kurulum tamamlanmamış olabilir. Bu olasılıklar için “passkey zaten eşitlenir” varsayımı yeterli değildir. Kurtarma senaryosunu cihaz ve sağlayıcı koşullarından bağımsız bir ürün gereksinimi olarak değerlendirin. Kullanıcı hangi güvenilir yolla hesabını geri alabilecek, hangi işlemler inceleme gerektirecek?

Kurtarma sürecinde güvenliği düşük bir kestirme yol eklemek, yeni giriş yönteminin sağladığı korumayı zayıflatabilir. Örneğin destek ekibi üzerinden yapılan değişikliklerin kanıt, yetki ve denetim kaydıyla yürütülmesini planlayın. Belirsiz durumda kullanıcıyı sonuçsuz tekrar denemelere yönlendirmek yerine anlaşılır bir destek adımı sunun. Kurtarma tamamlandığında eski erişimlerin nasıl ele alınacağı da kapsamda bulunmalıdır.

Test planında hangi durumlar olmalı?

Yeni hesap, mevcut hesap ve birden fazla giriş yöntemi kullanan hesapları ayrı test edin. Aynı kişinin farklı cihazlarda davranışı kadar farklı kullanıcıların aynı cihazdaki davranışını da inceleyin. Oturumdan çıkışın, kimlik bilgisi kaldırmanın ve hesap kapatmanın birbirinden farklı işlemler olduğunu arayüzde koruyun.

Önerilen kabul senaryoları şunlardır:

• Oluşturma işlemini iptal eden kullanıcı hesabına erişmeye devam eder.
• Yanlış hesaba bağlanma riski içeren giriş yolu ek doğrulamaya yönlenir.
• Bağlantı kesilmesi anlaşılır ve yeniden denenebilir bir sonuç üretir.
• Desteklenmeyen ortam alternatif akışa veya açıklamaya yönlendirilir.
• Sunucu doğrulaması başarısız olduğunda oturum oluşturulmaz.
• Erişim kurtarma talebi yetkili ve izlenebilir bir süreçten geçer.

Test sonuçlarını cihaz, uygulama sürümü ve giriş yöntemiyle birlikte değerlendirin. Başarı oranı veya süre iyileşmesi hakkında kendi veriniz olmadan kesin sonuç açıklamayın. İlk geçişi sınırlı bir kullanıcı grubuyla gözlemlemek, sorunları daha yönetilebilir bir kapsamda incelemek için değerlendirilebilecek bir yöntemdir.

Proje kapsamını doğru belirleyin

Passkey çalışması için mevcut hesap altyapısı, kullanıcı rolleri, oturum kuralları ve destek sürecini birlikte paylaşın. Webinle'nin mobil uygulama geliştirme hizmeti üzerinden giriş deneyiminizi ve sunucu entegrasyonu ihtiyacınızı değerlendirebilirsiniz. Hesap yaşam döngüsünün ayrı bir boyutu olan kapatma talepleri için mobil uygulamada hesap silme rehberini de inceleyin. Hedef, yeni bir düğme eklemek değil, erişimi güvenilir ve anlaşılır bir sürece dönüştürmektir.