WebAuthn Taşıyıcıları: Dahili ve Hibrit Taşıyıcılar

Passkeys for Super Funds and Financial Institutions
Join our Webinar on 7th November to learn how Super Funds and Financial Institutions can implement passkeys

Join now

Not: WebAuthn spesifikasyonuna göre, boş taşıyıcılar tüm taşıyıcıların desteklendiği anlamına gelir.

Passkey'leri platformlar arasında uygularken, geliştiriciler önemli bir kararla karşı karşıya kalır:

• Optimum cihazlar arası kimlik doğrulama deneyimleri sağlamak için WebAuthn taşıyıcılarını, özellikle de dahili ve hibrit taşıyıcıları nasıl yönetmeliyiz?

Cevap, doğrulayıcıların güvenen taraflarla nasıl iletişim kurduğunu belirleyen teknik bir ayrıntı olan WebAuthn taşıyıcılarını anlamakta yatar. Taşıyıcılar teoride basit görünse de, uygulamaları özellikle dahili ve hibrit taşıyıcıların yönetimi konusunda web tarayıcıları, native iOS ve native Android uygulamaları arasında önemli ölçüde farklılık gösterir.

Bu makale, WebAuthn taşıyıcılarının farklı platformlarda nasıl çalıştığını inceliyor ve dahili ile hibrit taşıyıcıları yönetmek için her birinin kendi avantaj ve dezavantajları olan iki farklı yaklaşım sunuyor.

Bu makalede ele alınan konular:

1. WebAuthn taşıyıcıları: web, iOS ve Android'de dahili, hibrit ve platform doğrulayıcıları
2. İki yaklaşım: spesifikasyona uygun vs. optimize edilmiş dahili ve hibrit taşıyıcı yönetimi
3. Cihazlar arası kimlik doğrulama uygulaması için en iyi pratikler ve öneriler

WebAuthn taşıyıcıları, doğrulayıcılar ile istemci cihazları arasındaki iletişim yöntemlerini tanımlar. WebAuthn Level 3 spesifikasyonu altı taşıyıcı türü tanımlar:

usb: YubiKey'ler veya diğer FIDO2 güvenlik token'ları gibi USB portları üzerinden bağlanan donanım güvenlik anahtarları tarafından kullanılır.

nfc: Yakın Alan İletişimi aracılığıyla doğrulayıcılarla iletişimi mümkün kılar, bu da kullanıcıların güvenlik anahtarlarına veya NFC özellikli cihazlarına dokunarak işlem yapmalarını sağlar.

ble: Bluetooth Düşük Enerji (Bluetooth Low Energy) üzerinden kimlik doğrulamayı kolaylaştırır ve harici doğrulayıcılarla kablosuz iletişimi mümkün kılar.

smart-card: Akıllı kart okuyucuları için kullanılır ve akıllı kartlar aracılığıyla kimlik doğrulamaya olanak tanır.

hybrid: Genellikle kullanıcının cihazlar arasında kimlik doğrulamak için bir QR kodu taradığı cihazlar arası kimlik doğrulamayı mümkün kılar. Örneğin, bir masaüstü tarayıcısında kimlik doğrulamak için telefonu kullanmak veya tam tersi. Bu taşıyıcı, hem masaüstü hem de mobil cihazlarda QR kodu istemlerini tetikleyebilir; bu durum, bağlama göre her zaman istenen bir durum olmayabilir. Not: hybrid WebAuthn Level 3 ile eklenmiştir.

internal: Doğrulayıcı, cihazın kendi içine gömülüdür. iPhone'lardaki iCloud Keychain (Face ID veya Touch ID ile doğrulanır), PC'lerdeki Windows Hello veya Android cihazlardaki Google Password Manager gibi. Bunlar platform doğrulayıcılarıdır.

Bir passkey oluşturulduğunda, doğrulayıcı hangi taşıyıcıları desteklediğini belirtir. Bu bilgi, güvenen tarafa (sizin arka ucunuz) gönderilir ve bu bilginin kimlik bilgisiyle birlikte saklanması gerekir. Kimlik doğrulama sırasında, güvenen taraf bu taşıyıcıları allowCredentials listesiyle istemciye geri gönderir. Bu, tarayıcının veya platformun kullanıcıya hangi kimlik doğrulama yöntemlerini sunacağını belirlemesine yardımcı olur.

Taşıyıcı yönetimi platformlar arasında önemli ölçüde farklılık gösterir, bu da geliştiricilerin karşılaştığı uyumluluk zorluklarını yaratır.

Tarayıcılar, taşıyıcı bilgilerini doğrulayıcılardan alır ve kimlik doğrulama akışları sırasında bu bilgilere uyar. Chrome, Safari veya Edge'de bir passkey oluşturduğunuzda, tarayıcının kimlik bilgisi yöneticisi, temel alınan doğrulayıcıya göre değişen taşıyıcı verileri sağlar:

Platform doğrulayıcıları: Windows Hello sadece ["internal"] sağlar, bu da cihaza bağlı doğasını yansıtır. Ancak, Chrome doğrulayıcı olarak Google Password Manager kullandığında, ["internal", "hybrid"] sağlar, çünkü Google Password Manager Android telefonlar aracılığıyla cihazlar arası kimlik doğrulamayı destekler.

Donanım güvenlik anahtarları: Gerçek yeteneklerine bağlı olarak ["usb", "nfc"] gibi belirli taşıyıcılar sağlar.

Bulut senkronizasyonlu kimlik bilgisi yöneticileri: Safari'deki iCloud Keychain ve Chrome'daki Google Password Manager genellikle hem yerel hem de cihazlar arası kimlik doğrulama akışlarını desteklemek için ["internal", "hybrid"] sağlar.

Bu bilgi web ortamlarında güvenilir bir şekilde akar, ancak belirli taşıyıcılar, tarayıcının kimlik bilgilerini depolamak için hangi doğrulayıcıyı seçtiğine bağlıdır.

Dokümantasyon: W3C WebAuthn Specification

Android'in Credential Manager API'si web tarayıcılarına benzer şekilde davranır. Native Android uygulamalarında passkey oluştururken, Credential Manager web davranışını yansıtan taşıyıcı bilgileri sağlar—platform doğrulayıcıları yeteneklerini doğru bir şekilde bildirir ve sistem taşıyıcı verilerini tutarlı bir şekilde yönetir. Android geliştiricileri, özel bir işlem yapmadan bu bilgilere güvenebilir.

Dokümantasyon: Android Credential Manager

iOS daha karmaşık bir durum sunar. Apple'ın AuthenticationServices framework'ü taşıyıcıları doğrulayıcı türüne bağlı olarak farklı şekilde yönetir:

Platform doğrulayıcıları (iCloud Keychain, Face ID veya Touch ID ile doğrulanır): Genellikle passkey oluşturma sırasında boş taşıyıcı dizileri döndürür. Bu, passkey'in taşıyıcı yeteneklerinden yoksun olduğu anlamına gelmez—sadece iOS'un bunları açıkça bildirmediği anlamına gelir. WebAuthn standardına göre, taşıyıcıları belirtmemek herhangi bir taşıyıcının kabul edilebilir olduğu anlamına gelir, bu nedenle hibrit kimlik doğrulama yine de çalışacaktır.

Güvenlik anahtarları: iOS cihazlarla kullanıldığında beklenen deseni izleyerek taşıyıcı bilgileri (ör. ["usb"], ["nfc"]) sağlar.

Dokümantasyon: Apple AuthenticationServices

Geliştiricilerin bir seçim yapması gerekir: spesifikasyona sıkı sıkıya uymak mı, yoksa kullanıcı deneyimi için dahili ve hibrit taşıyıcıları optimize etmek mi? Her yaklaşımın avantajları ve dezavantajları vardır.

Bu yaklaşım, WebAuthn spesifikasyonuyla uyumludur: kimlik bilgisi kaydı sırasında doğrulayıcı tarafından sağlanan taşıyıcıları olduğu gibi kullanın ve kimlik doğrulama sırasında bunları değiştirmeden geri gönderin.

Uygulama: Bir passkey oluşturulduğunda, doğrulayıcı yanıtından gelen transports dizisini saklayın. Kimlik doğrulama sırasında, bu taşıyıcıları allowCredentials listesine tam olarak dahil edin:

{
    "allowCredentials": [
        {
            "id": "credential-id-base64",
            "type": "public-key",
            "transports": ["internal", "hybrid"]
        }
    ]
}

Avantajları:

• Spesifikasyona uygunluk: WebAuthn standartlarını tam olarak takip eder, gelecekteki platform güncellemeleriyle uyumluluğu sağlar.
• Güvenlik anahtarı güvenilirliği: Her zaman doğru taşıyıcı bilgisi sağlayan donanım güvenlik anahtarları (YubiKey'ler vb.) için mükemmel çalışır.
• Geçersiz seçenekleri önler: Gerçekten desteklenmeyen kimlik doğrulama yöntemlerini sunmaktan kaçınır—örneğin, Windows Hello kimlik bilgileri için QR kodlarını tetiklemez.

Dezavantajları:

• iOS boş dizi davranışı: iOS'taki platform doğrulayıcıları boş taşıyıcılar döndürür, bu da spesifikasyona göre "herhangi bir taşıyıcı" anlamına gelir—bu durum güvenlik anahtarları da dahil olmak üzere tüm kimlik doğrulama seçeneklerini gösterebilir.
• İstenmeyen seçenekler gösterebilir: Tüketici uygulamalarında beklenmeyen güvenlik anahtarı seçeneklerini (USB, NFC) sunabilir.
• Tutarsız kullanıcı deneyimi: Farklı platformlar aynı hesap için farklı kimlik doğrulama seçenekleri sunar.

Kimler için en iyisi: Standartlara uygunluğa öncelik veren uygulamalar, çeşitli doğrulayıcı türlerine sahip kurumsal ortamlar.

Bu yaklaşım, belirli optimizasyon hedeflerine dayalı olarak dahili ve hibrit taşıyıcıları seçici bir şekilde değiştirerek kullanıcı deneyimini önceliklendirir. Genel bir kural yerine, bu yaygın optimizasyon senaryolarını göz önünde bulundurun:

Problem: iOS platform doğrulayıcıları boş taşıyıcı dizileri döndürür. Bu diziler boş bırakıldığında veya arka uç tarafından doldurulduğunda, kullanıcılar platform seçeneklerinin yanı sıra güvenlik anahtarı istemlerini (USB, NFC) görebilir, bu da tüketici uygulamalarında kafa karışıklığı yaratır.

Çözüm: iOS platform doğrulayıcıları için taşıyıcıları açıkça ["hybrid", "internal"] olarak ayarlayın. Bu, yalnızca platform kimlik doğrulamasının ve cihazlar arası akışların sunulmasını sağlar ve güvenlik anahtarı seçeneklerini gizler.

// iOS platform doğrulayıcı kimlik bilgilerini saklarken
if (platform === "iOS" && authenticatorAttachment === "platform") {
    transports = ["hybrid", "internal"];
}

Sonuç: iOS ile oluşturulan passkey'ler için güvenlik anahtarı istemleri olmadan temiz bir kimlik doğrulama arayüzü.

Problem: Mobil cihazlarda kimlik doğrulaması yaparken, cihazlar arası kimlik doğrulama için QR kodlarını göstermek kötü bir kullanıcı deneyimi yaratır—kullanıcılar zaten passkey'lerinin bulunduğu bir mobil cihazdadır.

Çözüm: Kullanıcı mobil bir cihazdan kimlik doğrulaması yaparken hybrid taşıyıcısını kaldırarak sadece ["internal"] bırakın.

// Kimlik doğrulama için allowCredentials oluştururken
const transports = isMobileDevice
    ? credentials.transports.filter((t) => t !== "hybrid")
    : credentials.transports;

Sonuç: Mobil kullanıcılar, gereksiz QR kodu istemleri olmadan yalnızca doğrudan kimlik doğrulama seçeneklerini görür.

⚠️ Dikkat: Taşıyıcı manipülasyonu her zaman platformlar arasında tutarlı sonuçlar vermez. Kapsamlı testler tarayıcı ve işletim sistemi kombinasyonlarının taşıyıcıları farklı şekilde yönettiğini göstermektedir:

• Bazı platformlar, hybrid taşıyıcılardan çıkarılsa bile QR kodları gösterir.
• Diğerleri, hybrid dahil olsa bile QR kodlarını gizler.
• Davranış, Windows, macOS ve iOS üzerinde Chrome, Edge, Safari ve Firefox arasında önemli ölçüde değişir.

Çıkmaz sokak riski: Aşırı kısıtlayıcı taşıyıcı filtrelemesi, kullanıcıların hiç giriş yapamadığı kimlik doğrulama çıkmazları yaratabilir. Örneğin, hybrid'i kaldırmak, bir kullanıcının ödünç alınmış bir cihazdan kimlik doğrulaması yapması gereken meşru cihazlar arası kimlik doğrulama senaryolarını engelleyebilir. Her zaman yedek kimlik doğrulama yöntemleri sağlayın ve taşıyıcı optimizasyonlarını dağıtmadan önce hedef platformlarınızda kapsamlı bir şekilde test edin.

Bunlar optimizasyon ipuçlarıdır: WebAuthn, kimlik doğrulama kullanıcı deneyimini optimize etmek için taşıyıcı manipülasyonunun ötesinde başka mekanizmalar da sunar—örneğin, ipuçları (hints).

Taşıyıcı davranışı öngörülemez: hybrid taşıyıcısı aracılığıyla cihazlar arası kimlik doğrulama (CDA), tarayıcı ve işletim sistemi kombinasyonları arasında tutarsız davranışlar sergiler. Gerçek dünya testleri taşıyıcı değerlerinin belirli bir kullanıcı arayüzü davranışını garanti etmediğini göstermektedir—platformlar taşıyıcıları farklı yorumlar ve yönetir, bu da beklenmedik sonuçlara yol açar.

Platforma özgü karmaşıklık: Taşıyıcıları açıkça kontrol ederken, platform farklılıklarını hesaba katmalısınız:

• iOS: Platform doğrulayıcıları için boş diziler gönderir; doldurma gerektirir.
• Windows Hello: Sadece ["internal"] olarak kalmalıdır; hybrid eklemek istenmeyen QR kodlarını tetikler.
• Web & Android: Genellikle doğru taşıyıcı bilgisi sağlar.
• CDA varyasyonları: QR kodu istemleri, hybrid taşıyıcı dizisinde bulunsun veya bulunmasın görünebilir veya kaybolabilir.

Uçtan uca anlayış gereklidir: Taşıyıcıları açıkça kontrol etmek, tüm akışın sorumluluğunu üstlenmek anlamına gelir. Her taşıyıcı kombinasyonunun tüm hedef platformlarınızda nasıl davrandığını anlamalı ve kapsamlı bir şekilde test etmelisiniz. Taşıyıcı manipülasyonu, kullanıcılar için geçerli bir kimlik doğrulama yolu bulunmayan kimlik doğrulama çıkmazları yaratabilir.

Avantajları:

• Özelleştirilmiş UX: Kullanıcıların belirli bağlamlarda hangi kimlik doğrulama seçeneklerini göreceğini tam olarak kontrol etme.
• iOS boş dizi sorununu çözer: iOS'un sağlamadığı durumlarda taşıyıcıları açıkça tanımlar.
• Bağlama duyarlı optimizasyon: Cihaz türüne göre kimlik doğrulama arayüzünü uyarlama.

Dezavantajları:

• Öngörülemeyen davranış: Taşıyıcı manipülasyonu tutarlı bir kullanıcı arayüzü davranışını garanti etmez—kapsamlı testler platformların taşıyıcıları farklı yorumladığını, bazen taşıyıcı değerlerine bakılmaksızın seçenekleri gösterip gizlediğini ortaya koyar.
• Kimlik doğrulama çıkmazları riski: Aşırı kısıtlayıcı taşıyıcı filtrelemesi, özellikle cihazlar arası senaryolarda kullanıcıların kimlik doğrulamasını tamamen engelleyebilir.
• Spesifikasyondan sapma: Spesifikasyon önerilerinden uzaklaşır, potansiyel olarak gelecekteki platform değişiklikleriyle sorunlara neden olabilir.
• Bakım yükü: Platformlar geliştikçe sürekli platforma özgü mantık ve güncellemeler gerektirir.
• Karmaşıklık: iOS boş dizilerini, Windows Hello kısıtlamalarını ve diğer platform tuhaflıklarını manuel olarak yönetmek gerekir.
• Test yükü: Her optimizasyon kuralının tüm platform kombinasyonlarında doğrulanması gerekir.

Kimler için en iyisi: Belirli kullanıcı deneyimi gereksinimleri olan tüketici uygulamaları, platforma özgü mantığı sürdürmek için kaynakları olan ekipler, sıkı spesifikasyon uyumluluğu yerine akıcı kimlik doğrulama akışlarını önceliklendiren senaryolar.

WebAuthn taşıyıcı yönetimi tek başına var olmaz—genel passkey uygulama stratejinizin bir parçasıdır. Üretim dağıtımlarında, her biri dahili ve hibrit taşıyıcı kullanımı için farklı sonuçları olan iki yaygın yaklaşım ortaya çıkar.

Bu yaklaşım, esnekliği ve standartlara uygunluğu önceliklendirir ve kullanıcıların herhangi bir uyumlu doğrulayıcı ile kimlik doğrulamasına olanak tanır.

Uygulama Özellikleri:

• Kimlik doğrulama arayüzü: Passkey butonu, mevcut giriş seçeneklerinin (kullanıcı adı/şifre) yanında görünür.
• allowCredentials: [] boş diziye ayarlanır, herhangi bir kimlik bilgisinin eşleşmesine izin verir.
• Doğrulayıcı türleri: Güvenlik anahtarları, cihazlar arası kimlik doğrulama (QR kodları), platform doğrulayıcıları desteklenir.
• Native uygulama gereksinimleri: Güvenlik anahtarları dahil tüm kimlik doğrulama yöntemlerini desteklemelidir.
• preferImmediatelyAvailableCredentials: Kullanılamaz, çünkü tanım gereği güvenlik anahtarlarını ve QR kodu girişlerini hariç tutar.
• Taşıyıcı yönetimi: Güvenlik anahtarı taşıyıcıları (usb, nfc, ble) dahil tüm taşıyıcı türlerini barındırmalıdır.

Taşıyıcı Etkileri:

Boş allowCredentials ile, kimlik doğrulama sırasında taşıyıcılar daha az kritik hale gelir—platform mevcut tüm seçenekleri gösterir. Ancak bu, kullanıcıların aynı anda güvenlik anahtarı istemlerini, QR kodlarını ve platform seçeneklerini görebileceği anlamına gelir, bu da tüketici uygulamalarında karar felcine neden olabilir.

Kimler için en iyisi: Kurumsal ortamlar, güvenlik anahtarı desteği gerektiren çeşitli kullanıcı tabanlarına sahip uygulamalar, maksimum kimlik doğrulama esnekliğini önceliklendiren senaryolar.

Bu yaklaşım, passkey oluşturmayı platform doğrulayıcılarıyla sınırlandırarak ve önce-tanımlayıcı akışlarını kullanarak tüketici kullanıcı deneyimini optimize eder.

Uygulama Özellikleri:

• Passkey oluşturma: Yalnızca authenticatorAttachment: "platform" aracılığıyla platform doğrulayıcılarına izin verilir.
• Kimlik doğrulama akışı: Önce-tanımlayıcı—kullanıcılar kimlik doğrulamadan önce e-posta/kullanıcı adını girer.
• allowCredentials: Tanımlayıcı bilindikten sonra kullanıcının belirli kimlik bilgileriyle doldurulur (boş değil).
• Doğrulayıcı türleri: Platform doğrulayıcıları ve cihazlar arası kimlik doğrulama; güvenlik anahtarları genellikle hariç tutulur.
• Native uygulama optimizasyonu: Tanım gereği güvenlik anahtarlarını ve cihazlar arası kimlik doğrulamayı hariç tutan preferImmediatelyAvailableCredentials kullanılabilir.
• Cihazlar arası kimlik doğrulama: Web'de mevcuttur; native uygulamalarda preferImmediatelyAvailableCredentials kullanıldığında mevcut değildir, ancak bu senaryo nadirdir (kullanıcıların genellikle kullandıkları cihazda passkey'leri vardır).
• Taşıyıcı yönetimi: Yalnızca internal ve hybrid taşıyıcılarına odaklanılmıştır.

Taşıyıcı Etkileri:

allowCredentials kendi taşıyıcılarıyla belirli kimlik bilgilerini içerdiğinden, taşıyıcı yönetimi kritik hale gelir.

Kimler için en iyisi: Tüketici uygulamaları, native mobil uygulamalar, doğrulayıcı esnekliği yerine akıcı kullanıcı deneyimini önceliklendiren senaryolar, önce-tanımlayıcı akışlarının zaten mevcut olduğu platformlar.

Hesap varlığını zaten sızdıran veya önce-tanımlayıcı akışlarını kullanan platformlar için (kullanıcı giriş seçeneklerini görmeden önce e-posta girer), tüketiciye yönelik yaklaşım doğal olarak uyum sağlar. Kullanıcı tanımlayıcısını sağladıktan sonra:

1. Arka uç, mevcut passkey'leri sorgular.
2. Belirli kimlik bilgileri ve taşıyıcılarıyla allowCredentials döndürür.
3. Platform, taşıyıcılara göre kimlik doğrulama arayüzünü optimize edebilir.
4. Ek hesap listeleme riski yoktur (tanımlayıcı zaten sağlanmıştır).

Bu senaryolarda, taşıyıcılar bir güvenlik endişesinden ziyade bir optimizasyon aracı haline gelebilir. Cihaz bağlamına (mobil vs. masaüstü) ve kimlik bilgisi yeteneklerine göre kimlik doğrulama seçeneklerini özelleştirebilirsiniz.

Öneri: Zaten önce-tanımlayıcı akışlarını kullanan veya hesap listelemenin bir endişe olmadığı platformlar için, açık taşıyıcı yönetimiyle tüketiciye yönelik yaklaşım, özellikle preferImmediatelyAvailableCredentials'in sorunsuz biyometrik kimlik doğrulamayı sağladığı native mobil uygulamalarda üstün bir kullanıcı deneyimi sunar.

Dahili ve hibrit taşıyıcıları yönetmek için hangi yaklaşımı seçerseniz seçin, sorunları en aza indirmek için şu pratikleri izleyin:

Kayıt Sırasında Taşıyıcıları Saklayın: Her zaman doğrulayıcı yanıtından gelen transports dizisini kimlik bilgisi ID'si ve genel anahtarla birlikte saklayın. Bu veri, kimlik doğrulama akışları için esastır.

Boş Dizileri Zarifçe Yönetin: iOS platform doğrulayıcılarından boş bir taşıyıcı dizisi aldığınızda:

• Spesifikasyona uygun: Boş bırakın veya taşıyıcılar özelliğini atlayın—bu "herhangi bir taşıyıcı kabul edilebilir" anlamına gelir.
• Optimizasyon yaklaşımı: Hangi kimlik doğrulama seçeneklerinin gösterileceğini kontrol etmek için ["internal", "hybrid"] ile doldurun.

Tüm Hedef Platformlarda Test Edin: Tüm kombinasyonları kapsayan bir test matrisi oluşturun:

• Kayıt: Web, iOS Native, Android Native
• Kimlik Doğrulama: Web, iOS Native, Android Native
• QR kodlarının beklendiğinde göründüğünü ve uygun olmadığında gizlendiğini doğrulayın.

Boş Dizi ve Eksik Özellik Arasındaki Farkı Anlayın: Hem boş bir [] taşıyıcı dizisi hem de eksik bir taşıyıcı özelliği, spesifikasyona göre genellikle "herhangi bir taşıyıcı kabul edilebilir" olarak kabul edilir. Ancak, uygulama ayrıntıları platformlar arasında farklılık gösterir.

Platform Değişikliklerini İzleyin: WebAuthn uygulamaları gelişir. Apple, Google ve Microsoft, doğrulayıcı davranışlarını düzenli olarak günceller. Taşıyıcı yönetimini etkileyebilecek değişiklikler hakkında bilgi sahibi olun.

WebAuthn taşıyıcıları—özellikle dahili ve hibrit taşıyıcılar—cihazlar arası kimlik doğrulama üzerinde önemli pratik etkilere sahip teknik ayrıntılardır. Taşıyıcı yönetimi stratejiniz, daha geniş passkey uygulama yaklaşımınız ve hedef platformlarınızla uyumlu olmalıdır.

Taşıyıcı Kararları Daha Geniş Bir Stratejinin Parçasıdır: Taşıyıcıları nasıl yöneteceğiniz, maksimum esneklik (boş allowCredentials) için mi yoksa tüketici kullanıcı deneyimi (belirli kimlik bilgileriyle önce-tanımlayıcı) için mi bir yapı kurduğunuza bağlıdır. İkincisi, taşıyıcıları optimizasyon için kritik hale getirir.

Platform Farklılıkları Yönetim Gerektirir: Web ve Android güvenilir taşıyıcı bilgileri sağlarken, iOS platform doğrulayıcıları boş diziler döndürür. Windows Hello yalnızca ["internal"] gönderir. Bu farklılıkları anlamak, üretim dağıtımları için esastır.

İki Geçerli Taşıyıcı Yaklaşımı: Spesifikasyona uygun (doğrulayıcı taşıyıcılarına güvenmek), kurumsal ve maksimum esneklik senaryoları için iyi çalışır. Açık kontrol (taşıyıcıları optimize etmek), önce-tanımlayıcı akışlarına sahip tüketici uygulamaları ve native mobil uygulamalar için uygundur.

Önce-Tanımlayıcı, Taşıyıcı Optimizasyonunu Mümkün Kılar: Kullanıcılar önce tanımlayıcılarını sağladığında, taşıyıcı yönetimi güçlü bir kullanıcı deneyimi aracı haline gelir. Mobil cihazlarda istenmeyen QR kodlarını önleyebilir, güvenlik anahtarı seçeneklerini gizleyebilir ve kimlik doğrulamayı akıcı hale getirebilirsiniz—ek hesap listeleme endişeleri olmadan.

Kurumsal / Maksimum Esneklik İçin:

• Tüm doğrulayıcı türlerini desteklemek için boş allowCredentials kullanın.
• Doğrulayıcı tarafından sağlanan taşıyıcılara güvenin.
• Kullanıcıların daha fazla kimlik doğrulama seçeneği gördüğünü kabul edin.
• Daha basit uygulama, daha geniş uyumluluk.

Tüketici Uygulamaları / Native Uygulamalar İçin:

• Önce-tanımlayıcı kimlik doğrulama akışını uygulayın.
• Platform doğrulayıcılarıyla sınırlayın (authenticatorAttachment: "platform").
• Belirli kimlik bilgileri ve optimize edilmiş taşıyıcılarla allowCredentials kullanın.
• Native uygulamalarda preferImmediatelyAvailableCredentials'i etkinleştirin.
• iOS boş dizilerini ["hybrid", "internal"] ile doldurun.
• QR kodlarını önlemek için mobil cihazlarda hybrid'i filtreleyin.
• Akıcı kimlik doğrulama seçenekleriyle üstün kullanıcı deneyimi.

Zaten Önce-Tanımlayıcı Akışları Olan Platformlar İçin:

• Hesap listeleme zaten bir sorun değildir.
• Tüketiciye yönelik yaklaşım, mevcut kullanıcı deneyimiyle doğal olarak uyum sağlar.
• Taşıyıcı optimizasyonu anında kullanıcı deneyimi faydaları sağlar.
• Çoğu tüketici uygulaması için önerilen yaklaşım.

Spesifikasyona uygun başlayın, ardından stratejinize göre optimize edin:

1. Kayıt sırasında alınan taşıyıcıları olduğu gibi saklayın.
2. Genel stratejinize karar verin (maksimum esneklik vs. tüketiciye yönelik).
3. Tüketiciye yönelik ise: önce-tanımlayıcı akışını uygulayın ve taşıyıcıları optimize edin.
4. Seçtiğiniz stratejiye uygun olarak iOS boş dizilerini yönetin.
5. Web, iOS Native ve Android Native platformlarında kapsamlı bir şekilde test edin.

WebAuthn dünyası gelişmeye devam ediyor. Platform satıcıları uygulamalarını düzenli olarak güncelliyor ve WebAuthn Level 3 gibi spesifikasyonlar yeni yetenekler sunuyor. Taşıyıcı yönetimini daha geniş kimlik doğrulama stratejinizle uyumlu hale getiren esnek sistemler oluşturmak, passkey uygulamanızın sağlam kalmasını ve ekosistem olgunlaştıkça mükemmel kullanıcı deneyimleri sunmasını sağlar.