Yerel Uygulama Geçiş Anahtarları: Yerel ve WebView Uygulaması Karşılaştırması

60-page Enterprise Passkey Whitepaper:
Learn how leaders get +80% passkey adoption. Trusted by Rakuten, Klarna & Oracle

Get free Whitepaper

Not: Sistem WebView ve Gömülü WebView genellikle bir arada kullanılır. Sistem WebView, kimlik bilgilerinin otomatik paylaşıldığı oturum açma işlemini yönetir, ardından Gömülü WebView, ayarlarda passkey yönetimini oluşturur.

Anahtar Karar Faktörleri:

• OAuth tabanlı oturum açma mı? → Sistem WebView (ASWebAuthenticationSession, Chrome Custom Tabs)
• Web kimlik doğrulamasını yerel bir kabukta yeniden kullanmak mı istiyorsunuz? → Gömülü WebView (WKWebView, WebKit 1.12.1+ ile Android WebView)
• Önceliği yerel olan bir uygulama mı geliştiriyorsunuz? → Yerel Uygulama (Apple AuthenticationServices, Google Credential Manager)

Modern mobil platformlar, passkey'leri yerel uygulamanıza entegre etmek için her biri kullanıcı deneyimi, teknik karmaşıklık ve OAuth uyumluluğu açısından farklı ödünler veren üç ayrı yaklaşım sunar:

1. Yerel Uygulama: Platform API'lerini (iOS AuthenticationServices, Android Credential Manager) kullanarak doğrudan uygulamanızın içine passkey akışları oluşturun. Sorunsuz biyometrik kimlik doğrulama ile en iyi kullanıcı deneyimini sağlar, ancak orta ila yüksek düzeyde teknik uygulama çabası gerektirir.

2. Sistem WebView: Kimlik doğrulamasını yönetmek için platformun tarayıcı bileşenini (iOS ASWebAuthenticationSession / SFSafariViewController, Android Chrome Custom Tabs) kullanın. OAuth tabanlı oturum açma akışları için mükemmeldir ve kimlik bilgilerini sistem tarayıcısıyla paylaşır.

3. Gömülü WebView: Web kimlik doğrulamasını yerel bir uygulama iskeletiyle yeniden kullanmak için uygulamanızın içine özelleştirilebilir bir web görünümü (iOS WKWebView, Android WebView) gömün. URL çubukları olmadan yerel benzeri bir görünüm ve web görünümü kullanıcı arayüzü üzerinde tam kontrol sağlar. Passkey işlevselliğini etkinleştirmek için izinler ve yetkilendirmeler (iOS) ve AndroidX WebKit 1.12.1+ (Android) ile WebView yapılandırması dahil olmak üzere ek kurulum gerektirir.

Doğru seçim, uygulamanızın kimlik doğrulama mimarisine, OAuth sağlayıcıları kullanıp kullanmadığınıza, kullanıcı arayüzü üzerinde ne kadar kontrole ihtiyacınız olduğuna ve önceliği yerel olarak mı geliştirdiğinize yoksa web bileşenlerini mi yeniden kullandığınıza bağlıdır.

Bir yerel passkey uygulaması, platforma özgü API'ler kullanılarak doğrudan uygulamanızın kullanıcı arayüzüne yerleştirilmiş kimlik doğrulama akışları ile en uygun kullanıcı deneyimini sağlar. Kullanıcılar, platforma özgü diyaloglardan, sorunsuz biyometrik doğrulamadan ve mümkün olan en hızlı oturum açma sürelerinden yararlanır.

Yerel Uygulamayı ne zaman seçmelisiniz:

• Yeni bir yerel uygulama oluştururken veya kimlik doğrulamasını yerel ekranlara yeniden düzenlerken
• Anında, sessiz kimlik doğrulama ile mümkün olan en iyi kullanıcı deneyimini istediğinizde
• Uygulama başlangıcında otomatik passkey istemleri: Yerel uygulamalar, passkey'ler mevcut olduğunda passkey katmanını otomatik olarak görüntülemek için preferImmediatelyAvailableCredentials kullanabilir, bu da kullanıcı adı girmeden en hızlı oturum açma deneyimini sağlar.
• Kimlik doğrulama kullanıcı arayüzü ve akışı üzerinde tam kontrole ihtiyaç duyduğunuzda
• Platforma özgü uygulamaya (iOS Swift, Android Kotlin) yatırım yapmaya istekli olduğunuzda

Anahtar Avantaj: preferImmediatelyAvailableCredentials()

Yerel uygulamalar, passkey'ler mevcut olduğunda uygulama başlangıcında hemen görünen otomatik bir passkey katmanı oluşturmak için preferImmediatelyAvailableCredentials()'dan yararlanabilir. Bu kullanıcı adısız akış, mümkün olan en hızlı oturum açma deneyimini sunar—kullanıcılar önce bir tanımlayıcı girmeden passkey'lerini anında görürler. Bu özellik, sadece yerel uygulamalara özeldir ve WebView çeşitlerinde mevcut değildir.

WebView uygulamaları Koşullu Arayüz (giriş alanlarındaki passkey önerileri) kullanabilse de, yerel uygulamanın otomatik katmanı, kimlik doğrulama uygulama açılır açılmaz başladığı için daha yüksek passkey kullanım oranlarıyla üstün bir UX sağlar.

Teknik Gereksinimlere Genel Bakış:

Yerel passkey entegrasyonu, uygulamanız ve web alan adınız arasında kriptografik güven gerektirir. Bu olmadan, işletim sistemi tüm WebAuthn işlemlerini reddedecektir. Anahtar gereksinimler:

1. /.well-known/ adresinde barındırılan Uygulama-Alan Adı İlişkilendirme Dosyaları
2. Web alan adınızla eşleşen Doğru Relying Party ID
3. Platforma Özgü Yetenekler (Bölüm 4'te ayrıntılı olarak açıklanmıştır)

En büyük fayda: web sitenizde oluşturulan passkey'ler, uygulamanızda ve tam tersi şekilde sorunsuzca çalışır.

iOS üzerinde passkey'leri yerel olarak uygulamak, WebAuthn işlemleri için bir API sağlayan Apple'ın AuthenticationServices çerçevesini içerir:

Anahtar Bileşenler:

• ASAuthorizationController: Kimlik doğrulama akışını yönetir
• ASAuthorizationPlatformPublicKeyCredentialProvider: Passkey istekleri oluşturur
• Passkey oturum açma işlemlerini yönetmek için üç farklı kullanıcı arayüzü modu:
  • Metin alanı girişi: Düğmeye tıklandığında passkey ile oturum açma başlayan geleneksel kullanıcı adı alanı
  • Passkey modal katmanı: Mevcut passkey'leri listeleyen işletim sistemi diyaloğu
  • Koşullu Arayüz: Klavyenin üzerindeki QuickType çubuğunda passkey önerileri

Geliştirme İpuçları

• AASA Önbellekleme: Apple, AASA dosyasını agresif bir şekilde (24 saate kadar) önbelleğe alır, bu da testleri zorlaştırabilir. Çözüm: Test cihazınızda Geliştirici Modunu etkinleştirin ve yeni verileri zorla çekmek için AASA URL'nize ?mode=developer ekleyin.
• Performans Testi: Gerçek dünya gecikmesini gözlemlemek için yüzlerce kimlik bilgisi içeren iCloud hesaplarıyla test yapın. Sistem katmanı, çok sayıda depolanmış passkey ile hafif bir gecikme gösterebilir.

Android'in yerel passkey uygulaması, Credential Manager API'sini (veya geri uyumluluk için daha eski FIDO2 API'sini) kullanır:

Anahtar Bileşenler:

• CredentialManager: Tüm kimlik bilgisi işlemleri için merkezi API
• CreatePublicKeyCredentialRequest: Passkey kaydı için
• GetCredentialRequest: Passkey kimlik doğrulaması için
• İki ana kullanıcı arayüzü modu:
  • Metin alanı girişi: Düğmeye tıklandığında passkey ile oturum açma başlayan geleneksel kullanıcı adı alanı
  • Passkey modal katmanı: Mevcut passkey'leri listeleyen işletim sistemi diyaloğu

Not: Android şu anda iOS'in yerel uygulamalardaki Koşullu Arayüz klavye önerilerinden yoksundur (ancak Koşullu Arayüz web uygulamalarında çalışır).

Passkey'leri yerel olarak uygulamak, önemli zorluklar ve öğrenilen dersler içerir: İşletim sistemi düzeyinde entegrasyon, farklı cihazlar ve işletim sistemi sürümleri arasında sorunlar ortaya çıkarabilir.

1. Örneğin, ekibimiz, Apple'ın apple-app-site-association dosyasını (uygulama/web kimlik bilgisi bağlantısı için kullanılır) agresif bir şekilde önbelleğe alması ve belirli Android OEM biyometrik istemlerindeki ince kullanıcı arayüzü farklılıkları gibi sorunlarla karşılaştı.
2. Ayrıca, bazı kurumsal senaryolarda, yönetilen cihazların passkey senkronizasyonunun ilke gereği devre dışı bırakılabileceğini göz önünde bulundurun. iCloud Keychain veya Google Password Manager senkronizasyonunun kapalı olduğu kurumsal ortamlarda, passkey'ler cihaza bağlı hale gelir ve dolaşmaz - bu, planlamanız gereken önemli bir senaryodur (örneğin, kullanıcıların yeni bir telefon aldıklarında hala oturum açabilmelerini sağlamak).
3. Ek olarak, üçüncü taraf kimlik bilgisi yöneticisi uygulamaları akışı etkileyebilir. Örneğin, bir kullanıcı 1Password gibi bir parola yöneticisini aktif bir kimlik bilgisi sağlayıcısı olarak ayarladıysa, bu genellikle passkey oluşturma ve depolamayı ele alarak platformun yerel kimlik bilgisi yöneticisinden öncelik alır.

Passkey'leri ham platform API'lerini kullanarak uygulayabilseniz de, amaca yönelik SDK'lar, WebAuthn karmaşıklığını, uç durumları ele alarak ve yerleşik telemetri sağlayarak geliştirmeyi önemli ölçüde hızlandırır. SDK'lar ayrıca birim testi için taklit edilebilir arayüzler sunar (simülatörlerde biyometriyi test edemeyeceğiniz için bu çok önemlidir).

Öneri: Yerel uygulamalar için, üretim dağıtımları aracılığıyla keşfedilen çok sayıda uç durumu ele alan, ek telemetri ve test sağlayan Corbado SDK'larını (iOS Swift Passkey SDK, Android Kotlin Passkey SDK) kullanmanızı öneririz.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

Milyonların benimsediği passkey'ler, hem de hızlıca. Corbado'nun Benimseme Platformu ile başlayın.

Ücretsiz Denemeyi Başlat

Sistem WebView'ları, uygulamanız içinde kimlik doğrulamasını yönetmek için platformun yerel tarayıcı bileşenini kullanır. Tamamen yerel uygulamaların aksine, Sistem WebView'ları web içeriğini gerçek sistem tarayıcısını (iOS'ta Safari, Android'de Chrome) kullanarak görüntüler, paylaşılan çerezleri, kaydedilmiş kimlik bilgilerini ve tanıdık tarayıcı güvenlik göstergelerini korur.

Sistem WebView'ı ne zaman seçmelisiniz:

• Uygulamanız OAuth tabanlı oturum açma kullanıyorsa: Sistem WebView, güvenli kimlik doğrulama sağlayan OAuth2/OIDC akışları için önerilen yaklaşımdır.
• Mobil uygulamalarda yeniden kullanmak istediğiniz mevcut web tabanlı kimlik doğrulamanız varsa
• Parolalar, sosyal giriş, passkey'ler gibi birden fazla kimlik doğrulama yöntemini yerel olarak yeniden oluşturmadan desteklemeniz gerekiyorsa
• Web ve mobil arasında tek bir kimlik doğrulama kod tabanını sürdürmek istediğinizde

Anahtar Avantajlar:

• OAuth uyumluluğu: OAuth/OIDC kimlik doğrulama akışları için özel olarak tasarlanmıştır
• Güvenlik göstergeleri: Kullanıcılar gerçek URL'yi ve SSL sertifikalarını görür, bu da güven oluşturur
• Düşük uygulama çabası: Minimum yerel kod gerektirir
• Tutarlı UX: Kullanıcıların zaten güvendiği tanıdık tarayıcı arayüzü

Platform Bileşenleri:

• iOS: ASWebAuthenticationSession (kimlik doğrulama akışları için önerilir) veya SFSafariViewController (genel tarama)
• Android: Chrome Custom Tabs (CCT)

Google ve GitHub gibi büyük şirketler, mobil uygulamalarına passkey ile oturum açma eklemek için mevcut web kimlik doğrulama sayfaları üzerindeki WebView katmanları aracılığıyla bu yaklaşımı benimsemiştir. Bu, tamamen yerel kimlik doğrulama yeniden oluşturmalarının hemen mümkün olmadığı durumlarda iyi çalışır.

iOS, kimlik doğrulama için iki ana Sistem WebView bileşeni sunar:

ASWebAuthenticationSession (Kimlik Doğrulama için Önerilir):

• OAuth/OIDC ve güvenli oturum açma akışları için özel olarak tasarlanmıştır
• Kullanıcıya uygulamanın kimlik doğrulamak istediğini otomatik olarak sorar
• Çerezleri ve kimlik bilgilerini Safari ile paylaşır
• iCloud Keychain aracılığıyla passkey'leri destekler

SFSafariViewController (Genel Tarama):

• Uygulama içinde tam Safari deneyimi
• URL çubuğunu ve güvenlik göstergelerini gösterir
• iOS 11+ üzerinde Safari çerezlerini paylaşmaz; Safari oturum paylaşımı gerektiğinde ASWebAuthenticationSession kullanın
• Daha az özelleştirilebilir ancak kullanıcılar için daha güvenilirdir

Uygulamanız OAuth tabanlı oturum açma kullanıyorsa, ASWebAuthenticationSession, özellikle kimlik doğrulama senaryoları için tasarlandığı ve güvenlik ile kullanıcı deneyimi arasında en iyi dengeyi sağladığı için önerilen seçimdir.

Chrome Custom Tabs (CCT), uygulamanız içinde Chrome destekli bir kimlik doğrulama deneyimi sunar:

Anahtar Özellikler:

• Çerezleri ve kimlik bilgilerini Chrome tarayıcısıyla paylaşır
• URL ve güvenlik göstergelerini gösterir
• Araç çubuğu rengini ve markalamayı özelleştirebilir
• Daha hızlı yükleme süreleri için ön ısıtma

OAuth Entegrasyonu: Chrome Custom Tabs, iOS ASWebAuthenticationSession'ın Android eşdeğeridir ve depolanan passkey'lere erişimi korurken mükemmel OAuth desteği sağlar.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

Gömülü WebView'lar, uygulamanız içinde web içeriği oluşturma üzerinde tam kontrol sağlar, çerezlerin, oturumların ve gezinmenin URL çubuğu olmadan doğrudan manipülasyonuna olanak tanır. Ancak bu kontrol, passkey işlevselliğini etkinleştirmek için ek teknik gereksinimlerle birlikte gelir.

Gömülü WebView'ı ne zaman seçmelisiniz:

• Yerel benzeri deneyim: Uygulamanız zaten yerel bir görünüm ve hissi korumak için kimlik doğrulamasını özelleştirilmiş bir web görünümü içine gömüyor ve bu tutarlı kullanıcı deneyimini sürdürmek istiyorsunuz.
• Oturum/çerez kontrolüne ihtiyaç duyma: Uygulamanız, OAuth kimlik doğrulaması tamamlandıktan sonra kimlik doğrulama belirteçlerinin ve oturum durumunun doğrudan manipülasyonunu gerektirir.
• Sistem WebView kimlik doğrulamasının bir kimlik doğrulama kodu döndürdüğü ancak gömülü bağlamlarda oturum döndürmediği mevcut kimlik doğrulama akışı.
• Birden çok gömülü web ekranında kimliği doğrulanmış durumu korumalıdır.
• Yalnızca birinci taraf kimlik doğrulaması: Uygulamanız kimlik doğrulamasını doğrudan yönetir, üçüncü taraf passkey uygulamaları için buraya bakın.
• Çalışma zamanı özellik tespiti ile AndroidX WebKit 1.12.1+.
• Oturum Açma için Koşullu Arayüz sınırlamasını kabul etme (Gömülü WebView'da desteklenmez), yönetim ayarları için ilgili değil.

Önemli Bağlam:

Birçok uygulama hibrit bir yaklaşım kullanır: Sistem WebView, ilk OAuth kimlik doğrulamasını (passkey'lerin sorunsuz çalıştığı yer) yönetir, ardından ayarlarda passkey'leri yönetmek için kimlik doğrulama sonrası Gömülü WebView'a geçer. Zorluklar, passkey'leri doğrudan Gömülü WebView'lar içinde kullanmaya çalışırken ortaya çıkar.

Teknik Gereksinimler:

Gömülü WebView'lar, Sistem WebView'larına kıyasla ek kurulum gerektirir:

1. iOS: İlişkili Alan Adları yetkilendirmeleri, AASA dosya yapılandırması
2. Android: WebView WebAuthn yapılandırması ile AndroidX WebKit 1.12.1+ (özellik tespiti gereklidir)
3. Her ikisi için: Düzgün yapılandırılmış well-known ilişkilendirme dosyaları ve Digital Asset Links

Platform Bileşenleri:

• iOS: WKWebView
• Android: android.webkit.WebView

Ödünler:

• Orta karmaşıklık: WebView yapılandırması (Android WebKit 1.12.1+) ve yetkilendirme kurulumu (iOS) gerektirir.
• Daha düşük passkey benimsenmesi: Kullanıcılar, yerel uygulamaya kıyasla daha fazla zorlukla karşılaşabilir.
• Koşullu Arayüz desteklenmez: Giriş alanlarında passkey otomatik doldurma Android Gömülü WebView'da çalışmaz.
• Sınırlı platform desteği: Bazı özellikler tutarlı bir şekilde çalışmayabilir (örneğin, otomatik passkey oluşturma).

Passkey'leri WebView'lar aracılığıyla uygularken, Sistem WebView'ları ile Gömülü WebView'lar arasındaki ayrımı anlamak çok önemlidir. Yukarıda özetlenen üç yaklaşım (Yerel Uygulama, Sistem WebView ve Gömülü WebView) her biri farklı kullanım durumlarına hizmet eder.

İOS'ta, uygulama içi web içeriğini görüntülemek için birden fazla seçeneğiniz vardır:

• WKWebView, WebKit çerçevesinin bir parçası olan (iOS 8'de tanıtıldı) özelleştirilebilir bir WebView'dur. Web içeriğinin görünümü ve davranışı üzerinde size çok fazla kontrol sağlar.
• SFSafariViewController, uygulamanız içinde hafif bir Safari tarayıcısı olarak işlev gören Apple tarafından sağlanan bir view controller'dır. Safari'nin motorunu kullanır. İOS 11+ üzerinde, ayrı bir çerez deposuna sahiptir ve Safari çerezlerini paylaşmaz. Safari oturum paylaşımı gerektiğinde ASWebAuthenticationSession kullanın.
• SFAuthenticationSession / ASWebAuthenticationSession, özellikle OAuth/OpenID veya diğer güvenli oturum açma akışları için tasarlanmış özel web kimlik doğrulama oturumlarıdır (iOS 11/12'den beri mevcuttur). Bunlar da perde arkasında Safari'yi kullanır, ancak kimlik doğrulama akışlarına odaklanmıştır ve paylaşılan çerezler ve Tek Oturum Açma (SSO) gibi şeyleri otomatik olarak yönetir.

Android'de ana seçenekler şunlardır:

• Android WebView, etkinliklerinize gömülebilen mini bir tarayıcı olan standart WebView widget'ıdır (android.webkit.WebView). Son derece özelleştirilebilirdir ancak uygulamanızın sürecinde çalışır.
• Chrome Custom Tabs (CCT), uygulamanızın bağlamında Chrome destekli bir sekme açan bir özelliktir. Custom Tabs, uygulamanızın bir parçası gibi görünür ancak Chrome tarayıcısı tarafından (yüklüyse) ön yükleme, paylaşılan çerezler ve kullanıcı güveni için tanıdık URL çubuğu gibi özelliklerle desteklenir.

Sonraki bölümlerde, iOS ve Android için bu WebView türlerine biraz daha derinlemesine dalacağız ve hangisinin passkey kimlik doğrulama akışları için en uygun olabileceğini tartışacağız.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Apple'ın platformu yukarıda listelenen üç WebView seçeneğini sunar. Seçiminiz, passkey'lerin uygulama içinde ne kadar sorunsuz kullanılabileceğini etkileyecektir:

iOS'taki farklı WebView davranışlarını test etmek için WebView - WKWebView and UIWebView rendering uygulamasını öneririz.

WKWebView, iOS için çok yönlü bir WebView bileşenidir. Geliştiriciler, kullanıcı arayüzü ve davranış üzerinde yüksek derecede kontrol ile web içeriğini oluşturmak için bir WKWebView gömebilir. WKWebView, Safari ile aynı işleme motorunu kullanır, bu nedenle çok performanslıdır ve modern web özelliklerini destekler. Teorik olarak, WKWebView doğru yapılandırılırsa WebAuthn'ı (ve dolayısıyla passkey'leri) yönetebilir, ancak bazı gelişmiş tarayıcı özelliklerinin güvenlik nedeniyle kısıtlanabileceğini unutmayın. Dikkat edilmesi gereken bir şey, izleme gereken, WKWebView'in varsayılan olarak çerezleri veya anahtar zinciri verilerini Mobil Safari ile paylaşmamasıdır. Kullanıcılar, WebView oturumları Safari'nin oturumundan izole olduğu için yeniden oturum açmak zorunda kalabilirler. Ayrıca, WKWebView içeriği uygulama tarafından tamamen özelleştirilebildiğinden, kullanıcı bir adres çubuğu veya Safari kullanıcı arayüzü görmez – bu markalaşma için harikadır, ancak kullanıcının sayfanın meşruiyetini doğrulamak için daha az ipucuna sahip olduğu anlamına gelir (bir oltalama karşıtı endişe). Bazı uygulamalar, komut dosyaları enjekte etmek veya içeriği değiştirmek için WKWebView'i kötüye kullanmıştır (örneğin, TikTok'un uygulama içi tarayıcısı aracılığıyla izleme JS enjekte ettiği belirtilmiştir), bu nedenle WKWebView'i güvenli, kullanıcıya güvenilir bir şekilde kullanmaya dikkat etmek gerekir.

SFSafariViewController, uygulama içi bir Safari deneyimi sunar. SFSafariViewController ile bir URL açtığınızda, bu neredeyse gerçek Safari tarayıcısında açmak gibidir, ancak kullanıcı uygulamanızın kullanıcı arayüzünde kalır. Passkey'ler için avantajı önemlidir: esasen Safari olduğu için, kullanıcının iCloud Keychain'i ve kayıtlı passkey'leri erişilebilirdir. Not: iOS 11+ üzerinde çerezler paylaşılmaz. Bu, kullanıcının siteniz için zaten bir passkey'i varsa, Safari'nin onu bulabileceği ve hatta kolay oturum açma için Koşullu Arayüz otomatik tamamlama özelliğini görüntüleyebileceği anlamına gelir. SFSafariViewController daha az özelleştirilebilirdir (araç çubuğunu çok fazla değiştiremezsiniz), ancak birçok güvenlik ve gizlilik özelliğini otomatik olarak yönetir. URL çubuğu, HTTPS için asma kilit simgesiyle birlikte gösterilir, bu da kullanıcılara doğru alan adında olduklarına dair güven verir. Genel olarak, SFSafariViewController ham bir WKWebView'den daha güvenli kabul edilir ve uygulanması daha basittir (Apple bunu hazır bir bileşen olarak sunar). Ana ödün, görünüm ve his üzerinde biraz kontrol kaybetmenizdir. Bir kimlik doğrulama akışı için bu genellikle kabul edilebilir. Buradaki öncelik, SFSafariViewController'ın Safari'nin bağlamını kullanarak mükemmel olduğu güvenlik ve oturum açma kolaylığıdır.

SFAuthenticationSession / ASWebAuthenticationSession – Bu sınıflar (ikincisi daha yeni Swift dostu addır) özellikle OAuth veya OpenID Connect gibi oturum açma akışları için oluşturulmuştur. Bir kullanıcıyı bir web sayfası aracılığıyla (belki harici bir IdP'ye) doğrulamanız gerektiğinde, bu oturumlar iOS'ta önerilen seçimdir. Bunlar, perde arkasında Safari tarayıcısını kullanmaları ve Safari ile çerezleri/depolamayı paylaşmaları açısından SFSafariViewController'a çok benzer. Anahtar fark, SFAuthenticationSession'ın her zaman kullanıcıya uygulamanın bir web sayfası kullanarak kimlik doğrulamak istediğini sorması (kullanıcı farkındalığı için) ve mevcutsa kullanıcının mevcut Safari oturumunu otomatik olarak kullanmasıdır.

Bunun faydası, sorunsuz bir SSO deneyimidir – eğer kullanıcı Safari'de sağlayıcıya zaten giriş yapmışsa, bu oturum başka bir girişten kaçınmak için bu çerezi kullanabilir. Passkey'ler için bu önemlidir, çünkü Safari/iCloud Anahtar Zinciri'nde depolanan herhangi bir passkey kimlik bilgisinin burada da kullanılabileceği anlamına gelir. Apple'ın resmi kılavuzu, oturum açma akışı gibi görünen her şey için ASWebAuthenticationSession kullanmaktır. Artıları, gelişmiş gizliliktir (uygulamanız kimlik bilgilerini veya çerezleri asla görmez, Safari halleder) ve yerleşik SSO desteğidir. Eksisi, kimlik doğrulama akışlarıyla sınırlı olmasıdır (uygulamanızda sadece rastgele web içeriği oluşturmak için kullanmazsınız). Özetle, iOS'ta bir WebView yaklaşımı seçerseniz, ASWebAuthenticationSession genellikle passkey'leri uygulamak için en iyi seçimdir çünkü güvenlidir, Safari ile durumu paylaşır ve kimlik doğrulama için özel olarak tasarlanmıştır.

Want to find out how many people use passkeys?

View Adoption Data

Android'de WebView kararı, klasik WebView ile Chrome Custom Tabs arasında verilir:

Android'deki farklı WebView davranışlarını test etmek için WebView vs Chrome Custom Tabs uygulamasını öneririz.

Android WebView (android.webkit.WebView), web sayfalarını etkinlik düzeninize gömmenizi sağlayan bir bileşendir. Gezinmeyi kesintiye uğratabilmeniz, JavaScript enjekte edebilmeniz, kullanıcı arayüzünü özelleştirebilmeniz vb. açısından WKWebView'e benzer. Ayrıca uygulamanızın sürecinde çalışır. Passkey'ler için bir WebView kullanmak, uygulamanızın web oturum açma sayfanızı yüklediği ve bu sayfanın bir WebAuthn passkey seremonisi başlatabileceği anlamına gelir. Modern Android WebView, WebAuthn'ı destekler (cihazın WebView uygulamasının Android Sistem WebView'u veya Chrome bileşeni aracılığıyla güncel olması koşuluyla). Önemli bir husus: varsayılan olarak, bir Android WebView çerezleri veya depolanan kimlik bilgilerini kullanıcının Chrome tarayıcısıyla paylaşmaz. Dolayısıyla, WebView'de oluşturulan veya kullanılan herhangi bir passkey, Chrome tarafından bilinmeyebilir ve tersi de geçerlidir. Bu izolasyon güvenlik için iyi olabilir (uygulamanız tarayıcı çerezlerini okuyamaz), ancak kullanıcılar Chrome'da zaten kimlik doğrulaması yapmışlarsa onları tekrar oturum açmaya zorlayabilir. Başka bir sorun da güvendir. Düz bir WebView, URL'yi veya SSL kilit simgesini göstermez, bu nedenle kullanıcılar uygulamanıza onları oltalamayacağına dair tamamen güvenmek zorundadır. Google, potansiyel oltalama (phishing) riskleri nedeniyle Google OAuth oturum açmaları için WebView kullanımını bile yasaklamıştır. Performans açısından WebViews iyidir, ancak özellikle ağır sayfalar yükleniyorsa, kullanıcının varsayılan tarayıcısını kullanmaktan daha yavaş veya daha fazla bellek yoğun olabilirler.

Chrome Custom Tabs (CCT) hibrit bir yaklaşımdır. Uygulamanızın, uygulamanızın bir parçası gibi görünen Chrome tarafından oluşturulmuş bir sayfa açmasına izin verirler. Araç çubuğu rengini özelleştirebilir, bir uygulama logosu ekleyebilirsiniz vb., ancak içerik ayrı bir süreçte Chrome tarafından oluşturulur. Passkey'ler için, CCT'lerin birkaç faydası vardır: kullanıcının çerezlerini ve kimlik bilgilerini Chrome ile paylaşırlar, yani kullanıcı Chrome aracılığıyla (Google Parola Yöneticisi) bir passkey kaydetmişse, Custom Tab buna erişebilir. Kullanıcı ayrıca gerçek URL'yi ve güvenlik göstergelerini görecektir, bu da güven oluşturur. Performans genellikle daha iyidir – Chrome, daha hızlı yükleme için arka planda "ısınabilir". Ve önemli olarak, güvenlik güçlüdür: esasen Chrome uygulaması olduğu için, Google Güvenli Tarama gibi şeyler oturumu korur ve uygulamanız sayfaya keyfi komut dosyaları enjekte edemez (belirli saldırıları önler).

Dezavantajı, kullanıcının Chrome'u (veya desteklenen bir tarayıcıyı) yüklemiş ve güncel tutmuş olmasını gerektirmesidir. Çoğu Android kullanıcısı bunu yapar, ancak belirli bölgelerdeki bazı cihazlarda bu bir sorun olabilir. Genel olarak, Android'de gömülü bir web yaklaşımıyla giderseniz, Chrome Custom Tabs, entegrasyon ve güvenlik arasında iyi bir denge sağladıkları için passkey akışları için önerilir. Aslında, bunlar iOS'in SFSafariViewController/ASWebAuthSession'ına birçok yönden benzerler – kimlik doğrulama için varsayılan tarayıcıdan yararlanırlar.

(Not: Apple'ın WKWebView vs SFSafariViewController ve Android'in WebView vs CCT'si arasında birçok paralellik vardır. Hem Safari VC hem de Chrome Tabs tarayıcı durumunu paylaşır ve daha iyi güvenlik sağlar, oysa WKWebView/Android WebView daha fazla kontrol verir ancak web içeriğini izole eder. Passkey'ler için, durumun paylaşılması (çerezler, kimlik bilgisi depoları) genellikle arzu edilir, böylece passkey'e sorunsuz bir şekilde erişilebilir ve oluşturulabilir.)

Hangi uygulama yaklaşımını seçerseniz seçin, passkey işlevselliğini etkinleştirmek için belirli teknik gereksinimlerin karşılanması gerekir. Bu bölüm, well-known ilişkilendirme dosyalarını, iOS yetkilendirmelerini ve Android WebView yapılandırmasını yapılandırma konusunda kapsamlı rehberlik sağlar.

Yönetilen Cihazlar Üzerine Not: Passkey davranışı, Mobil Cihaz Yönetimi (MDM) politikalarının kimlik bilgisi depolamasını kontrol ettiği yönetilen cihazlarda önemli ölçüde değişir. Yönetilen cihazlarda passkey'leri test etmek için bkz. Yönetilen iOS ve Android Cihazlarında Passkey'ler.

Yerel ve Gömülü WebView akışları, uygulamanız ve web alan adınız arasında kriptografik güven oluşturmak için ilişkilendirme dosyaları gerektirir. Sistem WebView (ASWebAuthenticationSession) ve Chrome Custom Tabs, uygulamadan siteye ilişkilendirme gerektirmez.

AASA dosyası, iOS uygulamanız ve web alan adınız arasındaki bağlantıyı kurarak passkey'lerin her iki platformda da çalışmasını sağlar.

Dosya Konumu: https://alanadiniz.com/.well-known/apple-app-site-association

Yapılandırma Gereksinimleri:

• Alan adınızda /.well-known/apple-app-site-association adresinde barındırın
• Geçerli bir SSL sertifikasıyla HTTPS üzerinden sunun
• Content-Type: application/json
• .well-known yolunda yönlendirme olmamalıdır
• Uygulamanızın Team ID ve Bundle ID'sini ekleyin

Örnek AASA Dosyası:

{
    "webcredentials": {
        "apps": ["TEAMID123.com.example.app"]
    }
}

AASA Önbellekleme ve Test:

Apple, AASA dosyalarını (24-48 saate kadar) bir CDN kullanarak agresif bir şekilde önbelleğe alır, bu da geliştirme ve testleri zorlaştırabilir. Geliştirme sırasında önbelleğe almayı atlamak için:

1. Test cihazınızda Geliştirici Modunu etkinleştirin
2. Xcode'daki ilişkili alan adınıza ?mode=developer ekleyin
3. Bu, iOS'u en son AASA dosyasını doğrudan sunucunuzdan çekmeye zorlar

⚠️ Önemli: Üretim sürümlerinde ?mode=developer kullanmayın. Bu parametre yalnızca geliştirme içindir - üretimde kullanmak, iOS'un AASA dosyanızı doğru bir şekilde algılamasını engelleyerek passkey işlevselliğini bozar.

Doğrulama: Yapılandırmanızı doğrulamak için Apple'ın AASA Doğrulayıcısını kullanın.

Android, uygulamanız ve web siteniz arasındaki ilişkiyi doğrulamak için Digital Asset Links kullanır.

Dosya Konumu: https://alanadiniz.com/.well-known/assetlinks.json

Yapılandırma Gereksinimleri:

• Alan adınızda /.well-known/assetlinks.json adresinde barındırın
• Geçerli sertifika ile HTTPS üzerinden sunun
• Content-Type: application/json
• Uygulamanızın SHA256 parmak izini (imzalama sertifikasından) ekleyin

Örnek assetlinks.json Dosyası:

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls",
            "delegate_permission/common.get_login_creds"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.example.app",
            "sha256_cert_fingerprints": [
                "AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99"
            ]
        }
    }
]

Doğrulama: Yapılandırmanızı oluşturmak ve doğrulamak için Google'ın Digital Asset Links Oluşturucusunu kullanın.

iOS uygulamaları, passkey işlevselliğine erişmek için uygun yetkilendirmelere ihtiyaç duyar. Gereksinimler, uygulama yaklaşımınıza göre biraz farklılık gösterir.

Yetkilendirme dosyası (genellikle Flutter uygulamalarında Runner.entitlements veya yerel iOS projelerinde UygulamaAdiniz.entitlements olarak adlandırılır), Apple'ın sistemi tarafından verilen özel izinleri ve yetenekleri tanımlar. Passkey'ler için bu dosya, İlişkili Alan Adlarını (Associated Domains) yapılandırır.

Dosya Konumu: Genellikle Xcode projenizde ios/Runner/Runner.entitlements adresinde bulunur

Yerel Uygulama ve Gömülü WebView, uygulamanızı web alan adınızla ilişkilendirmek için İlişkili Alan Adları yeteneğini gerektirir. Sistem WebView (ASWebAuthenticationSession), Safari bağlamında çalıştığı için bunu gerektirmez.

Xcode'da Kurulum:

1. Projenizi Xcode'da açın
2. Uygulama hedefinizi seçin
3. "Signing & Capabilities" sekmesine gidin
4. "+ Capability"e tıklayın ve "Associated Domains" ekleyin
5. Alan adınızı webcredentials: ön ekiyle ekleyin

Örnek Yapılandırma:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.developer.associated-domains</key>
    <array>
        <string>webcredentials:alanadiniz.com</string>
        <string>webcredentials:altalanadi.alanadiniz.com</string>
    </array>
</dict>
</plist>

Çoklu Alan Adları: Uygulamanızın birden fazla alan adıyla çalışması gerekiyorsa, İlgili Köken İstekleri (ROR) gerekebilir.

Android Gömülü WebView'lar, AndroidX WebKit 1.12 ile yerel WebAuthn desteği kazandı ve bu da özel JavaScript köprü kodu ihtiyacını ortadan kaldırdı. Sistem WebView (Chrome Custom Tabs) herhangi bir yapılandırma gerektirmez - kimlik bilgileri otomatik olarak çalışır.

Gereksinimler:

• AndroidX WebKit 1.12.1 veya daha yenisi (1.14.0+ önerilir)
• Yapılandırılmış Digital Asset Links
• WebAuthn destekli WebView APK'sı (özellik tespiti yoluyla kontrol edin)
• Not: AndroidX Credentials kütüphanesi WebView WebAuthn için GEREKLİ DEĞİLDİR, yalnızca tamamen yerel uygulamalar için gereklidir

Uygulama:

import androidx.webkit.WebSettingsCompat
import androidx.webkit.WebViewFeature
 
// Web Authentication'ın desteklenip desteklenmediğini kontrol edin
if (WebViewFeature.isFeatureSupported(WebViewFeature.WEB_AUTHENTICATION)) {
    // Web Authentication'ı etkinleştirin
    WebSettingsCompat.setWebAuthenticationSupport(
        webView.settings,
        WebSettingsCompat.WEB_AUTHENTICATION_SUPPORT_FOR_APP
    )
 
    // JavaScript'i etkinleştirin
    webView.settings.javaScriptEnabled = true
}

Anahtar Noktalar:

• JavaScript köprüsü gerekmez: WebAuthn, WebView'de yerel olarak çalışır
• Özellik tespiti gereklidir: Çalışma zamanında her zaman WebViewFeature.WEB_AUTHENTICATION kontrol edin
• Koşullu Arayüz desteklenmez: mediation:"conditional" (giriş alanlarında passkey otomatik doldurma) Gömülü WebView'de çalışmaz
• Yedek strateji: Özellik mevcut değilse, bunun yerine Chrome Custom Tabs kullanın

Sürüm Notları:

• WebKit 1.12.1 veya daha yenisini kullanın (1.12.0'da bir çalışma zamanı kullanılabilirlik sorunu vardı)
• Özellik desteği, kullanıcının WebView APK sürümüne bağlıdır - cihazdaki eski APK'lar özelliği göstermez

AndroidX WebKit 1.12.0'dan önce, Gömülü WebView'de yerel WebAuthn desteği yoktu. Ekipler şunlardan birini yapmak zorundaydı:

1. Chrome Custom Tabs veya Auth Tab kullanmak (önerilir)
2. Özel bir JavaScript köprüsü oluşturmak

Eski Android sürümlerini veya güncellenmemiş WebView APK'larına sahip cihazları desteklemeniz gerekiyorsa, köprü kodu yaklaşımı için Android'in Credential Manager WebView Entegrasyon kılavuzuna bakın. Ancak, modern uygulamalar için yerel WebKit 1.12.1+ yaklaşımını kullanmanızı şiddetle tavsiye ederiz.

Öneri: AndroidX WebKit 1.12.1+ ile yerel WebAuthn desteğini kullanın. Çalışma zamanında mevcut değilse, paylaşılan kimlik bilgileriyle mükemmel passkey desteği sağlayan Chrome Custom Tabs'e geri dönün.

Yerel uygulamalarda passkey'leri uygularken, uygulamanız ve web alan ad(lar)ınız arasında güven oluşturmanız gerekir. Bu bölüm, tek bir alan adını, birden çok ilgili alan adını (ROR) nasıl yöneteceğinizi ve well-known ilişkilendirme dosyalarınızın doğru yapılandırılıp yapılandırılmadığını nasıl doğrulayacağınızı kapsar.

Tek bir alan adı kullanan uygulamalar için (ör. kayak.com), şunlara ihtiyacınız vardır:

• iOS için https://kayak.com/.well-known/apple-app-site-association adresinde bir AASA dosyası
• Android için https://kayak.com/.well-known/assetlinks.json adresinde bir assetlinks.json dosyası
• webcredentials:kayak.com ile yapılandırılmış İlişkili Alan Adları yetkilendirmesi

İlgili Kökenler (ROR), tek bir passkey setinin birden çok ilgili alan adında (ör. kayak.com, kayak.de, kayak.co.uk) çalışmasına olanak tanıyan bir WebAuthn özelliğidir. ROR, ilgili kökenleri tanımlamak için her sitedeki /.well-known/webauthn uç noktasını kullanır, AASA veya assetlinks dosyalarını DEĞİL.

Anahtar Noktalar:

• ROR yapılandırması: Her alan adı, ilgili kökenlerin listesini içeren /.well-known/webauthn'ı barındırır
• Uygulama ilişkilendirme dosyaları (AASA/assetlinks): Yalnızca uygulamaları ilgili web siteleriyle eşleştirmek için kullanılır
• iOS 18+ Gömülü WebView: Doğru yapılandırıldığında ROR'u destekler
• İlişkili Alan Adları yetkilendirmeleri: Uygulamanızın kimlik doğrulaması yapması gereken tüm alan adlarını içerir

Yapılandırma Örneği:

Uygulamanız kayak.com ve kayak.de ile çalışıyorsa, her iki alan adı da şunları yapmalıdır:

• Aynı Team ID ve Bundle ID ile kendi AASA dosyalarını barındırmalıdır
• Uygulamanızın İlişkili Alan Adları yetkilendirmelerinde listelenmelidir
• Düzgün yapılandırılmış ve erişilebilir well-known dosyalarına sahip olmalıdır

Canlıya geçmeden önce, well-known dosyalarınızın doğru yapılandırıldığını ve erişilebilir olduğunu doğrulayın. Apple ve Google, dosya kullanılabilirliğini kontrol etmek için CDN tabanlı test URL'leri sağlar:

Bu Test URL'lerini Kullanma:

• Apple/Google'ın well-known dosyalarınızı alıp alamadığını doğrulamak için bağlantılara tıklayın
• Apple'ın ?nocache=1 parametresi, CDN önbelleğini atlayarak yeni bir alım zorlar
• Dosyalar bu URL'ler aracılığıyla erişilebilir değilse, passkey işlevselliği uygulamanızda çalışmaz
• Yukarıdaki URL desenlerinde kayak.com veya kayak.de'yi kendi alan ad(lar)ınızla değiştirin

Test İpucu: Tüm alan adlarının doğru yapılandırılmış well-known dosyalarına sahip olduğundan emin olun. Herhangi bir alan adında eksik veya yanlış yapılandırılmış bir dosya, o alan adı için passkey işlevselliğini bozabilir.

Daha Fazla Bilgi: Yerel Uygulamalarda WebAuthn Relying Party ID

Doğru uygulama yaklaşımını seçmek, uygulamanızın kimlik doğrulama mimarisine, OAuth gereksinimlerine ve oturum kontrolü ihtiyacına bağlıdır. İleriye dönük en iyi yolu belirlemek için bu karar ağacını kullanın.

Bu anahtar sorularla başlayın:

1. Uygulamanız OAuth tabanlı oturum açma (OAuth2, OIDC, sosyal giriş sağlayıcıları) kullanıyor mu?

   • Evet → Sistem WebView (Bölüm 1.2)
     • iOS: ASWebAuthenticationSession kullanın
     • Android: Chrome Custom Tabs kullanın
     • Paylaşılan kimlik bilgileriyle mükemmel OAuth desteği

2. Web kimlik doğrulamasını yerel benzeri bir kabukta (URL çubuğu yok, tam kullanıcı arayüzü kontrolü) yeniden kullanmak istiyor musunuz?

   • Evet → Yapılandırmalı Gömülü WebView (Bölüm 1.3)
   • iOS: WKWebView + İlişkili Alan Adları yetkilendirmeleri
   • Android: WebView + AndroidX WebKit 1.12.1+ yapılandırması
   • Web bileşenlerini yeniden kullanırken yerel benzeri görünüm sağlar
   • Not: Koşullu Arayüz, Gömülü WebView'de desteklenmez
   • Hayır → Sistem WebView veya Yerel Uygulamayı düşünün

3. Yeni bir yerel uygulama mı oluşturuyorsunuz veya yerel oturum açma ekranlarınız var mı?

   • Evet → Yerel Uygulama (Bölüm 1.1)
     • En iyi kullanıcı deneyimi
     • Anında, sessiz kimlik doğrulama
     • Platforma özgü geliştirme gerektirir

4. Yeniden kullanmak istediğiniz mevcut web kimlik doğrulamanız var mı?

   • Evet → Hızlı uygulama için Sistem WebView
   • Hayır → Optimal UX için Yerel Uygulama

Her yaklaşımın anahtar boyutlarda nasıl performans gösterdiği aşağıda verilmiştir:

Boyut Açıklamaları:

• Passkey Oluşturma: Kullanıcıların bu yaklaşımla ne kadar kolay passkey oluşturabildiği
• Passkey Kullanma: Mevcut passkey'leri kullanırken kimlik doğrulama deneyimi
• Passkey Yönetimi: Kullanıcıların passkey'leri nasıl görüntülediği, düzenlediği veya sildiği
• Teknik Karmaşıklık: Geliştirme çabası ve devam eden bakım
• OAuth Desteği: Yaklaşımın OAuth2/OIDC kimlik doğrulama akışlarını ne kadar iyi yönettiği
• Kurulum Süresi: Tipik uygulama zaman çizelgesi

Önerilen: Sistem WebView

Uygulamanız OAuth2, OIDC veya sosyal giriş sağlayıcıları (Google, GitHub, Microsoft, vb.) aracılığıyla kimlik doğrulaması yapıyorsa, Sistem WebView en uygun seçimdir:

• iOS: ASWebAuthenticationSession OAuth akışları için özel olarak tasarlanmıştır
• Android: Chrome Custom Tabs sorunsuz OAuth entegrasyonu sağlar
• Faydaları: Minimal yerel kod, otomatik kimlik bilgisi paylaşımı
• Uygulama: Web kimlik doğrulama sayfanıza WebAuthn ekleyin, ardından Sistem WebView aracılığıyla yükleyin

Örnek: kayak.com ve kayak.de gibi seyahat uygulamaları kimlik doğrulama için OAuth kullanır. Sistem WebView, web kimlik doğrulama sayfaları aracılığıyla passkey desteği eklerken mevcut OAuth altyapılarını korumalarına olanak tanır.

Önerilen: Hibrit Yaklaşım

İlk OAuth kimlik doğrulaması için Sistem WebView'ı kullanın, ardından kimlik doğrulaması sonrası oturumlar için Gömülü WebView'ı kullanın:

1. İlk Kimlik Doğrulama: Sistem WebView, OAuth + passkey oturum açmayı yönetir
2. Oturum Yönetimi: Çerez/oturum kontrolüne ihtiyaç duyduğunuz kimliği doğrulanmış web içeriği için Gömülü WebView'a geçin
3. Teknik Kurulum: Hem Sistem hem de Gömülü WebView gereksinimlerini yapılandırın - Android için, AndroidX WebKit 1.12.1+'in dahil edildiğinden emin olun (bkz. Bölüm 5)

Ne zaman kullanılır: OAuth aracılığıyla kimlik doğrulaması yapan ancak daha sonra doğrudan oturum manipülasyonunun gerekli olduğu kimliği doğrulanmış web içeriğini görüntülemesi gereken uygulamalar.

Önerilen: Yerel Uygulama

Sıfırdan mı oluşturuyorsunuz veya yerel ekranlarınız mı var? Tamamen yerel gidin:

• iOS: AuthenticationServices çerçevesini kullanın
• Android: Credential Manager API'sini kullanın
• Faydaları: En iyi UX, anında kimlik doğrulama, tam kontrol
• Benzersiz Avantaj: Uygulama başlangıcında otomatik passkey katmanı göstermek için preferImmediatelyAvailableCredentials kullanın - yerel uygulamalara özeldir ve en yüksek dönüşüm oranlarını sağlar
• SDK Önerisi: Üretimde test edilmiş uç durum yönetimi ile geliştirmeyi hızlandırmak için Corbado SDK'larını (iOS, Android) kullanın

Yeni Uygulamalar İçin: İlk günden itibaren yerel oturum açma oluşturmanızı şiddetle tavsiye ederiz. Sizi optimal UX için hazırlar ve gelecekteki WebView'dan yerel uygulamaya geçişlerden kaçınır.

Önerilen: Aşamalı Geçiş

• Aşama 1: Sistem WebView Passkey'leri - Mevcut web oturum açma işlemine passkey desteği ekleyin, Sistem WebView (ASWebAuthenticationSession/Chrome Custom Tabs) aracılığıyla yükleyin. Minimal yerel kodla hızlı bir kazanç.
• Aşama 2: Yerel Müdahale - WebView'i göstermeden önce yerel passkey kontrolü ekleyin. Örnek: kayak.com önce yerel passkey kimlik doğrulamasını dener, gerekirse WebView'e geri döner. Geriye dönük uyumluluğu korurken hızlı biyometrik oturum açma sağlar.
• Aşama 3: Tam Yerel - Eski yöntemler için WebView'i koruyarak, passkey kullanıcıları için kademeli olarak yerel kimlik doğrulamasına geçin.

Bu aşamalı yaklaşım, mevcut kullanıcıları rahatsız etmeden artımlı iyileştirmelere olanak tanır.

Ayrıntılı yapılandırma talimatları için Bölüm 5'e bakın.

Yerel uygulamalarda passkey'leri test etmek, yapılandırılmış, çok katmanlı bir yaklaşım gerektirir. Test piramidini takip edin: birim testleri (izole mantık), entegrasyon testleri (simülatörlerde/emülatörlerde WebAuthn seremonisi) ve sistem testleri (fiziksel cihazlarda uçtan uca).

Temel Test Kategorileri:

• Temel Yolculuklar: Kayıt, kimlik doğrulama, cihazlar arası akışlar, passkey silme
• Platform Kapsamı: iOS (yerel), Android (yerel), işletim sistemi sürümleri genelinde web tarayıcıları
• Alan Adı İlişkilendirmesi: AASA dosyalarının (iOS) ve Digital Asset Links'in (Android) erişilebilir olduğunu doğrulayın
• İptal Akışları: İşletim sistemi istemlerinde ve biyometrik ekranlarda kullanıcı iptalini test edin
• Hata Yönetimi: Arka uç hataları, ağ zaman aşımları, kimlik bilgisi uyuşmazlıkları
• Uç Durumlar: Ekran kilidi devre dışı, iCloud/Google Parola Yöneticisi devre dışı
• OAuth Akışları: OAuth + passkey entegrasyonunu uçtan uca tamamlayın
• Yönetilen Cihazlar: MDM kontrollü ortamlar (bkz. yönetilen cihaz testi)
• Üçüncü Taraf Yöneticiler: 1Password, Bitwarden, Dashlane uyumluluğu
• Cihazlar Arası Kimlik Doğrulama: QR kod akışları ve hibrit taşıma testi
• Gömülü WebView'e Özgü: Gömülü WebView kullanıyorsanız, Android'de WebKit 1.12.1+ yapılandırmasını doğrulayın
• Üretim İzleme: Başarı oranları, hatalar ve gecikme için gösterge paneli

Otomasyon stratejileri, platforma özgü püf noktaları ve eksiksiz bir uçuş öncesi kontrol listesi de dahil olmak üzere kapsamlı test rehberliği için özel kılavuzumuza bakın: Yerel iOS ve Android Uygulamalarında Passkey Akışlarını Test Etme.

Kullanıcıları geleneksel oturum açma (parola, OAuth) başarılı olduktan sonra passkey oluşturmaya teşvik etmeyi düşünün. Bu kademeli dönüşüm yaklaşımı:

• Mevcut kimlik doğrulama akışlarını bozmaz
• Kullanıcı reddederse zarif bir şekilde geri çekilmeye izin verir
• Değişiklikleri zorlamadan zamanla passkey benimsemesini artırır
• Her üç uygulama yaklaşımıyla da iyi çalışır

Örnek: Sistem WebView aracılığıyla OAuth ile oturum açtıktan sonra, yerel bir istem gösterin: "Face ID ile daha hızlı oturum açmayı etkinleştirin mi?" Kabul edilirse, Sistem WebView'de yüklenen web sayfası aracılığıyla passkey oluşturun.

Passkey'leri nasıl uygulayacağınıza karar vermek - Yerel Uygulama, Sistem WebView veya Gömülü WebView aracılığıyla - güvenliği, kullanıcı deneyimini ve geliştirme karmaşıklığını etkileyen önemli bir tasarım seçimidir. Her duruma uyan tek bir cevap yoktur.

OAuth tabanlı uygulamalar için: Sistem WebView (ASWebAuthenticationSession, Chrome Custom Tabs) önerilen başlangıç noktasıdır. Mükemmel OAuth desteği, minimum uygulama çabası ve otomatik kimlik bilgisi paylaşımı sağlar.

Yerel odaklı uygulamalar için: Er ya da geç yerel uygulamaya geçin. Yerel bir passkey ile oturum açma, WebView uygulamalarının sağlayamadığı preferImmediatelyAvailableCredentials gibi özel yeteneklerle en sorunsuz kullanıcı deneyimini sunar; bu özellik uygulama başlangıcında otomatik passkey katmanı sağlar. iOS ve Android'in artık passkey'ler için birinci sınıf destek sağlamasıyla, gerçek dünya başarıları yüksek benimseme oranları göstermektedir. Araçlar (açık kaynaklı SDK'lar ve platform kütüphaneleri dahil) yerel entegrasyonu makul zaman dilimlerinde gerçekleştirilebilir kılmak için olgunlaşmıştır. Cihaz yönetimi politikalarını, cihazlar arası senkronizasyonu ve üçüncü taraf sağlayıcıları göz önünde bulundurmanız gerekse de, bu zorluklar dikkatli mühendislik ve testlerle yönetilebilir. Sonuç, kullanıcıları kolaylığı ve hızıyla memnun eden ve güvenliği önemli ölçüde artıran bir uygulama oturum açma deneyimidir.

Gömülü WebView çerçeve gereksinimleri için: Gömülü WebView, iki gerçek dünya senaryosunda yaygın olarak kullanılır. Birincisi, OAuth tabanlı uygulamalar genellikle ilk oturum açma akışı için Sistem WebView'ı kullanır, ardından oturum kontrolünün gerekli olduğu ayar ekranlarında passkey yönetim seçeneklerini oluşturmak için Gömülü WebView'a geçer - ancak bazı uygulamalar her iki akış için de Sistem WebView'ı kullanarak bunu basitleştirir. İkincisi, passkey'leri benimsemeden önce kimlik doğrulama akışlarını zaten WebView çerçevelerine gömmüş olan uygulamalar, tutarlılık için bu modeli sürdürür. Yerel WebAuthn destekli Gömülü WebView (AndroidX WebKit 1.12.1+), yapılandırma ve kurulum (izinler, yetkilendirmeler, WebView ayarları) gerektirir, ancak artık özel JavaScript köprü koduna ihtiyaç duymaz. Koşullu Arayüzün Gömülü WebView'de desteklenmediğini unutmayın. Mevcut gömülü kimlik doğrulama modellerini sürdürürken veya kimlik doğrulama sonrası ekranlar için oturum/çerez kontrolüne ihtiyaç duyduğunuzda bu yaklaşımı seçin.

Sonuç olarak, yerel uygulamalardaki passkey'ler hem kullanıcı rahatlığı hem de güvenlik açısından büyük bir sıçramayı temsil eder. İster Yerel, ister Sistem WebView, ister Gömülü WebView aracılığıyla uygulansın, kullanıcılarınız için oltalama (phishing) risklerini ve parola yönetimi yüklerini ortadan kaldırırlar. VicRoads'un yerel uygulama passkey entegrasyonu gibi gerçek dünya uygulamaları, otomatik passkey katmanları gibi özelliklerle doğru şekilde yürütüldüğünde yerel odaklı yaklaşımların en yüksek kullanıcı benimsemesini ve memnuniyetini sağladığını göstermektedir. Kullanıcı dostu kimlik doğrulama için en iyi uygulamaları takip ederek ve uygulamanızın mimarisine uyan uygulama yaklaşımını seçerek - yeni uygulamalar için yerel odaklı, OAuth akışları için Sistem WebView veya mevcut gömülü desenler için Gömülü WebView - herkes için basit, güvenli ve keyifli kimlik doğrulama olan parolasız, biyometrik oturum açma işlemleri sunabilirsiniz.

Passkey'ler yerel uygulamanızda çalışmıyorsa, uygulama yaklaşımına göre bu yaygın sorunları kontrol edin:

• Dosyalar geçerli bir sertifika ile HTTPS üzerinden sunuluyor
• Doğru MIME türü: application/json
• .well-known yolunda yönlendirme yok
• iOS: Team ID ve Bundle ID, AASA dosyasında tam olarak eşleşiyor
• Android: SHA256 parmak izi, assetlinks.json'daki imzalama sertifikanızla eşleşiyor
• Relying Party ID, alan adınızla eşleşiyor (protokol yok, port yok)
• RP ID'de sonda eğik çizgi yok
• WebAuthn kökeni: https://alan-adiniz.com (app:// değil)

• iOS: Xcode'da webcredentials:alanadiniz.com ile İlişkili Alan Adları yeteneği etkinleştirilmiş
• Android: AndroidManifest.xml'de Digital Asset Links bildirilmiş
• Kullanıcının ekran kilidi etkin (biyometrik veya PIN)
• Apple'ın AASA Doğrulayıcısı ve Google'ın Digital Asset Links aracıyla test edin
• Runner.entitlements dosyasının doğru ilişkili alan adlarını içerdiğini doğrulayın

• iOS: ASWebAuthenticationSession (önerilir) veya SFSafariViewController kullanılıyor
• Android: Chrome Custom Tabs kullanılıyor (düz WebView değil)
• iOS: Gerekirse İlişkili Alan Adlarının yapılandırıldığını doğrulayın
• Çerezlerin/kimlik bilgilerinin sistem tarayıcısıyla paylaşıldığını test edin
• Web kimlik doğrulama sayfasının uygun WebAuthn uygulamasına sahip olduğunu doğrulayın

• iOS: Uygun yetkilendirmelerle yapılandırılmış
• iOS: İlişkili Alan Adları tüm ilgili alan adlarını içeriyor
• iOS: AASA dosyası erişilebilir ve doğru biçimlendirilmiş
• iOS: Geliştirme sırasında ?mode=developer ile test edin (üretim için kaldırın)
• Android: AndroidX WebKit 1.12.1+ (veya daha yenisi) projeye dahil edilmiş
• Android: WebViewFeature.WEB_AUTHENTICATION için çalışma zamanı özellik kontrolü
• Android: setWebAuthenticationSupport() WEB_AUTHENTICATION_SUPPORT_FOR_APP ile çağrılmış
• Android: WebView ayarlarında JavaScript etkinleştirilmiş
• Android: Kullanıcının WebView APK sürümü WebAuthn özelliğini destekliyor (işletim sistemi sürümünü değil, özellik tespitini kullanın)
• Koşullu Arayüz kullanılmıyor (Gömülü WebView'de desteklenmez)
• WebAuthn özelliği mevcut değilse Chrome Custom Tabs'e geri dönün

• Kullanıcının varsayılan olmayan bir kimlik bilgisi sağlayıcısının (1Password, Bitwarden, vb.) aktif olup olmadığını kontrol edin
• Sağlayıcının passkey'leri destekleyip desteklemediğini doğrulayın (tüm parola yöneticileri desteklemez)
• Platformun yerel kimlik bilgisi yöneticisiyle (iCloud Keychain, Google Parola Yöneticisi) test edin

"NotAllowedError: İstek, mevcut bağlamda kullanıcı aracısı veya platform tarafından izin verilmiyor"

• Genellikle anlamı: Eksik yetkilendirmeler (iOS) veya WebView özelliği mevcut değil/etkin değil (Android Gömülü WebView)
• Kontrol edin: İlişkili Alan Adları yapılandırması, AASA dosyası erişilebilirliği, WebKit sürümü, özellik tespiti, setWebAuthenticationSupport() çağrısı

Hiçbir passkey istemi görünmüyor

• Anlamı olabilir: AASA/assetlinks.json yüklenmiyor, yanlış WebView türü, önbelleğe alınmış AASA dosyası
• Deneyin: İlişkilendirme dosyalarını doğrulayın, test için iOS'ta ?mode=developer kullanın, WebView türünü doğrulayın

Ayrıntılı hata ayıklama için, yerel uygulamalarda Relying Party ID'leri hakkındaki makalemize bakın.

Corbado Yerel SDK'ları:

• iOS SDK (Swift)
• Android SDK (Kotlin)
• Flutter Package

Platform Dokümantasyonu:

• Apple: Supporting Passkeys
• Google: Credential Manager

Doğrulama Araçları:

• Apple AASA Validator
• Google Digital Asset Links Generator