WebAuthn Taşıyıcıları: Internal ve Hybrid Taşıyıcı

Kurumsal Passkey Whitepaper. Passkey programları için pratik rehberler, geçiş kalıpları ve KPI'lar.

Whitepaper al

Not: WebAuthn spesifikasyonuna göre, boş bir taşıyıcı dizisi taşıyıcı bilgisinin kullanılamadığı veya gizlilik amacıyla saklandığı anlamına gelir. Genellikle tarayıcılar tarafından tüm taşıyıcıların mümkün olabileceği şeklinde değerlendirilir.

Platformlar arası geçiş anahtarlarını (passkeys) uygularken geliştiriciler önemli bir kararla karşı karşıya kalır:

• En uygun çapraz cihaz kimlik doğrulaması deneyimlerini sağlamak için WebAuthn taşıyıcılarını, özellikle internal ve hybrid taşıyıcıları nasıl ele almalısınız?

Cevap, kimlik doğrulayıcıların bağlı taraflarla (relying parties) nasıl iletişim kuracağını belirleyen teknik bir detay olan WebAuthn taşıyıcılarını anlamakta yatmaktadır. Taşıyıcılar teoride basit görünse de, uygulamaları web tarayıcıları, yerel iOS ve yerel Android uygulamaları arasında, özellikle de internal ve hybrid taşıyıcı işlemede ö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 internal ile hybrid taşıyıcıları işlemek için her birinin kendi artıları ve eksileri olan iki farklı yaklaşım sunuyor.

Bu makale şunları kapsamaktadır:

1. WebAuthn taşıyıcıları: web, iOS ve Android genelinde internal, hybrid ve platform kimlik doğrulayıcıları
2. İki yaklaşım: spesifikasyon uyumlu vs optimize edilmiş internal ve hybrid taşıyıcı işleme
3. Çapraz cihaz kimlik doğrulama uygulaması için en iyi uygulamalar ve öneriler

WebAuthn taşıyıcıları, kimlik doğrulayıcılar ve 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 tokenleri gibi USB bağlantı noktaları üzerinden bağlanan donanım güvenlik anahtarları tarafından kullanılır.

nfc: Yakın Alan İletişimi (NFC) aracılığıyla kimlik doğrulayıcılarla iletişimi sağlar, kullanıcıların güvenlik anahtarlarını veya NFC özellikli cihazlarını dokundurmalarına olanak tanır.

ble: Bluetooth Düşük Enerji üzerinden kimlik doğrulamayı kolaylaştırarak harici kimlik doğrulayıcılarla kablosuz iletişim sağlar.

smart-card: Akıllı kart okuyucuları için kullanılır, akıllı kartlar üzerinden kimlik doğrulamaya izin verir.

hybrid: Genellikle kullanıcının masaüstü tarayıcısında kimlik doğrulamak için telefonu kullanarak QR kodu tarattığı gibi çapraz cihaz kimlik doğrulamasına olanak tanır. Bu taşıyıcı, bağlama bağlı olarak her zaman istenmeyebilecek şekilde hem masaüstü hem de mobil cihazlarda QR kodu istemlerini tetikleyebilir. Not: hybrid, WebAuthn Level 3'te eklenmiştir.

internal: Kimlik doğrulayıcı cihazın kendi içine yerleştirilmiştir; iPhone'lardaki (Face ID veya Touch ID ile doğrulanan) iCloud Keychain, PC'lerdeki Windows Hello veya Android cihazlardaki Google Password Manager gibi. Bunlar platform kimlik doğrulayıcılarıdır.

Bir geçiş anahtarı oluşturulduğunda, kimlik doğrulayıcı hangi taşıyıcıları desteklediğini bildirir. Bu bilgi, bağlı tarafa (arka ucunuza) gönderilir ve bu bilginin kimlik bilgisiyle birlikte saklanması gerekir. Kimlik doğrulama sırasında bağlı taraf, bu taşıyıcıları allowCredentials listesinde istemciye geri göndererek 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 ve geliştiricilerin karşılaştığı uyumluluk zorluklarını yaratır.

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

Platform kimlik doğrulayıcıları: Windows Hello, cihaza bağlı yapısını yansıtacak şekilde yalnızca ["internal"] sağlar. Ancak Chrome, kimlik doğrulayıcı olarak Google Password Manager'ı kullandığında, Google Password Manager Android Telefonlar aracılığıyla çapraz cihaz kimlik doğrulamasını desteklediği için ["internal", "hybrid"] sağlar.

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, hem yerel hem de çapraz cihaz kimlik doğrulama akışlarını desteklemek için genellikle ["internal", "hybrid"] sağlar.

Belirli taşıyıcılar tarayıcının kimlik bilgisi depolama için hangi kimlik doğrulayıcıyı seçtiğine bağlı olsa da, bu bilgi web bağlamlarında güvenilir bir şekilde akar.

Dokümantasyon: W3C WebAuthn Spesifikasyonu

Android'in Credential Manager API'si de web tarayıcılarına benzer şekilde davranır. Yerel Android uygulamalarında geçiş anahtarları oluşturulurken, Credential Manager web davranışını yansıtan taşıyıcı bilgileri sağlar; platform kimlik 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şleme gerek duymadan bu bilgiye güvenebilirler.

Dokümantasyon: Android Credential Manager

iOS daha karmaşık bir durum sunar. Apple'ın AuthenticationServices çerçevesi, taşıyıcıları kimlik doğrulayıcı türüne bağlı olarak farklı şekilde işler:

Platform kimlik doğrulayıcıları (iCloud Keychain, Face ID veya Touch ID ile doğrulanır): Geçiş anahtarı oluşturma sırasında genellikle boş taşıyıcı dizileri döndürürler. Bu, taşıyıcı bilgisinin kullanılamadığını veya gizlilik nedeniyle saklandığını gösterir; WebAuthn spesifikasyonuna göre, kullanıcı aracıları taşıyıcı bilgisi bilinmediğinde veya gizliliği korumak için boş diziler döndürebilir. Bağlı taraflar taşıyıcıları garantilerden ziyade ipuçları olarak değerlendirmelidir.

Güvenlik anahtarları: Beklenen kalıbı izleyerek iOS cihazlarıyla kullanıldıklarında taşıyıcı bilgisi (ör. ["usb"], ["nfc"]) sağlarlar.

Dokümantasyon: Apple AuthenticationServices

Web ve yerel uygulamalardan gelen gerçek dünya üretim verileri, sıklığa göre sıralanmış aşağıdaki taşıyıcı kalıplarını ortaya koymaktadır. Bu dağılımların uygulama detaylarından ve istemci demografisinden (mobil ile masaüstü kullanımı, yerel uygulamaların mevcudiyeti) etkilendiğini unutmayın, ancak tipik taşıyıcı kullanımına dair değerli içgörüler sağlarlar:

Önemli Çıkarımlar:

Platform kimlik doğrulayıcıları hakimdir: Geçiş anahtarlarının büyük çoğunluğu internal taşıyıcı kullanır, genellikle çapraz cihaz kimlik doğrulaması desteği için hybrid ile birleştirilir. Bu, platform kimlik doğrulayıcılarına (iCloud Keychain, Google Password Manager) odaklanan tüketici yapısını yansıtır.

Boş diziler yaygındır: iOS yerel uygulamaları sıklıkla platform kimlik doğrulayıcıları için boş taşıyıcı dizileri döndürür ve üretim kimlik bilgilerinin önemli bir bölümünü temsil eder. Bölüm 2.2.3'te tartışıldığı gibi, bunlar kapsamlı taşıyıcı desteğinden ziyade kullanılamayan taşıyıcı bilgisini gösterir.

Güvenlik anahtarları nadirdir: Donanım güvenlik anahtarları (usb, nfc), üretim geçiş anahtarlarının küçük bir bölümünü oluşturur, bu da bunların tüketici uygulamalarından ziyade kurumsal veya yüksek güvenlikli senaryolarda kullanıldığını gösterir.

Sıralama varyasyonları vardır: Dizilerdeki taşıyıcıların sırası (["internal", "hybrid"]'e karşı ["hybrid", "internal"]) platforma ve kimlik doğrulayıcı uygulamasına göre değişir ancak işlevsel bir fark taşımaz - her ikisi de aynı taşıyıcı yöntemleri için desteği belirtir.

Eski terminoloji: cable taşıyıcı tanımlayıcısı eski uygulamalarda ara sıra görünür ve hybrid ile eş anlamlıdır (caBLE = cloud-assisted Bluetooth Low Energy, hybrid taşıyıcının orijinal adı).

Bu dağılım, geçiş anahtarı uygulamalarının büyük çoğunluğunu oluşturdukları için internal ve hybrid taşıyıcıları doğru kullanmanın önemini pekiştirmektedir.

Taşıyıcı mevcudiyeti, ortaya çıkan akışın tamamlanıp tamamlanmadığını değil, kimlik doğrulayıcıların ne bildirdiğini gösterir. Corbado Passkey Benchmark 2026 çapraz cihaz kimlik doğrulama tamamlama analizi, 2026 1. Çeyrek hybrid taşıyıcı tamamlamasını genel olarak Windows web'de %60–78 ve macOS web'de %66–86 olarak ölçmekte olup, bu aynı cihaz teşvikleri için %79–98 (Win) / %83–98 (macOS) ile önce tanımlayıcı akışları için %52–67 (Win) / %59–76 (macOS) olarak ayrılmaktadır. hybrid'i yönlendirme mantığındaki en yüksek maliyetli taşıyıcı olarak kabul edin ve kullanıcıyı kimlik bilgisini barındıran cihazda tutan akışları tercih edin.

Aynı kimlik doğrulayıcı genellikle platform, sürüm ve uygulama bağlamına bağlı olarak farklı taşıyıcı kalıpları bildirir. Bu varyasyon normaldir ve beklenen bir durumdur:

iCloud Keychain üç kalıp sergiler:

• ["internal", "hybrid"] - En yaygın, genellikle web tarayıcılarından
• [] (boş dizi) - Çok yaygın, iOS yerel uygulamalarından
• ["hybrid", "internal"] - Daha az yaygın, sıralama varyasyonu
• Yalnızca ["internal"] veya ["hybrid"] - Nadir uç durumlar

Google Password Manager en çok varyasyonu gösterir:

• ["hybrid", "internal"] - En yaygın kalıp
• ["internal", "hybrid"] - Yaygın alternatif sıralama
• ["internal", "cable"] - Eski uygulamalar (cable = hybrid için eski terim)
• [] (boş dizi) - Belirli yerel bağlamlardan
• Tekli taşıyıcılar nadiren

Windows Hello en tutarlı olanıdır:

• ["internal"] - Hakim kalıp (tasarımı gereği cihaza bağlı)

1Password, Bitwarden, Dashlane ve LastPass gibi şifre yöneticilerinin tümü benzer varyasyon kalıpları gösterir:

• Hem ["internal", "hybrid"] hem de ["hybrid", "internal"] sıralamaları
• Yerel uygulama bağlamlarından boş diziler []
• Bazen yalnızca ["internal"]

Samsung Pass (Android ekosistemi) temel olarak şunları kullanır:

• ["hybrid", "internal"] ve ["internal", "hybrid"] - Her iki sıralama da yaygındır

Platform farklılıkları: Aynı kimlik doğrulayıcı web'e karşı yerel, iOS'a karşı Android veya Windows'a karşı macOS'ta farklı davranır.

Sürüm evrimi: Taşıyıcı raporlaması zamanla gelişti. Eski sürümler hybrid yerine cable kullanabilir veya farklı kombinasyonlar bildirebilir.

Uygulama tercihleri: Bazı kimlik doğrulayıcılar önce internal, diğerleri hybrid'e öncelik verir. Sıralamanın işlevsel bir etkisi yoktur ancak uygulamaya göre değişir.

Bağlam hassasiyeti: Yerel uygulamalar, özellikle iOS'ta, web bağlamlarında tam taşıyıcı bildiren kimlik doğrulayıcılardan bile genellikle boş diziler alır.

Temel Çıkarım: Belirli bir kimlik doğrulayıcı için taşıyıcı dizilerinin tutarlı olacağını varsaymayın. Uygulamanızı, kesin dizi eşleştirmesinden ziyade belirli taşıyıcıların varlığına odaklanarak tüm varyasyonları sorunsuz bir şekilde yönetecek şekilde tasarlayın.

Geliştiriciler bir seçimle karşı karşıyadır: spesifikasyonu kesin olarak takip etmek veya internal ve hybrid taşıyıcıları kullanıcı deneyimi için optimize etmek. Her iki yaklaşımın da avantajları ve dezavantajları vardır.

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

Uygulama: Bir geçiş anahtarı oluşturulduğunda, kimlik doğrulayıcı yanıtından gelen transports dizisini kalıcı olarak kaydedin. Kimlik doğrulama sırasında, bu tam taşıyıcıları allowCredentials listesine ekleyin:

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

Avantajlar:

• Spesifikasyon uyumluluğu: Gelecekteki platform güncellemeleriyle uyumluluğu sağlayarak WebAuthn standartlarını hassas bir şekilde takip eder
• Güvenlik anahtarı güvenilirliği: Her zaman doğru taşıyıcı bilgisini sağlayan donanım güvenlik anahtarları (YubiKey'ler vb.) için mükemmel çalışır
• Geçersiz seçenekleri önler: Gerçekte desteklenmeyen kimlik doğrulama yöntemleri sunmaktan kaçınır; örneğin, Windows Hello kimlik bilgileri için QR kodlarını tetiklemez

Dezavantajlar:

• iOS boş dizi davranışı: iOS'taki platform kimlik doğrulayıcıları, kullanılamayan taşıyıcı bilgisini gösteren boş taşıyıcılar döndürür; platformlar, hangi kimlik doğrulama seçeneklerinin gösterileceğini belirlerken bunu farklı şekillerde yorumlayabilir
• İstenmeyen seçenekler gösterebilir: Tüketici uygulamalarında beklenmeyen yerlerde 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

Şunlar için en iyisidir: Standartlara uyumluluğu önceliklendiren uygulamalar, çeşitli kimlik doğrulayıcı türlerine sahip kurumsal ortamlar.

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

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

Çözüm: iOS platform kimlik 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 çapraz cihaz akışlarının sunulmasını sağlayarak güvenlik anahtarı seçeneklerini gizler.

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

Sonuç: iOS'ta oluşturulan geçiş anahtarları için güvenlik anahtarı istemleri olmayan temiz kimlik doğrulama kullanıcı arayüzü.

Sorun: Mobil cihazlarda kimlik doğrulaması yaparken, çapraz cihaz kimlik doğrulaması için QR kodları göstermek kötü bir kullanıcı deneyimi (UX) yaratır; kullanıcılar zaten geçiş anahtarlarının bulunduğu bir mobil cihazdadır.

Çözüm: Kullanıcı bir mobil cihazdan kimlik doğrulaması yaptığında hybrid taşıyıcıyı kaldırın ve geriye yalnızca ["internal"] kalsı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ı tutarlı sonuçlar üretmez. Kapsamlı testler, tarayıcı ve işletim sistemi kombinasyonlarının taşıyıcıları farklı şekilde işlediğini göstermektedir:

• Bazı platformlar, taşıyıcılardan hybrid hariç tutulduğunda bile QR kodlarını gösterir
• Diğerleri, hybrid eklendiğinde bile QR kodlarını gizler
• Davranış; Windows, macOS ve iOS genelinde 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çbir şekilde oturum açamadığı kimlik doğrulama çıkmazları (deadends) yaratabilir. Örneğin, hybrid'i kaldırmak, kullanıcının ödünç alınmış bir cihazdan kimlik doğrulaması yapması gereken meşru çapraz cihaz kimlik doğrulama senaryolarını önleyebilir. Taşıyıcı optimizasyonlarını devreye almadan önce her zaman yedek kimlik doğrulama yöntemleri sağlayın ve hedef platformlarınızda kapsamlı bir şekilde test edin.

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

Taşıyıcı davranışı öngörülemez: hybrid taşıyıcı aracılığıyla çapraz cihaz kimlik doğrulaması (CDA), tarayıcı ve işletim sistemi kombinasyonları arasında tutarsız davranışlar sergiler. Gerçek dünyadaki testler, taşıyıcı değerlerinin belirli kullanıcı arayüzü davranışlarını garanti etmediğini göstermektedir; platformlar taşıyıcıları farklı şekilde yorumlar ve yönetir, bu da beklenmeyen 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 kimlik doğrulayıcıları için boş diziler gönderir; doldurma gerektirir
• Windows Hello: Yalnızca ["internal"] kalmalıdır; hybrid eklemek istenmeyen QR kodlarını tetikler
• Web ve Android: Genellikle doğru taşıyıcı bilgisini sağlar
• CDA varyasyonları: Taşıyıcı dizisinde hybrid varlığından bağımsız olarak QR kodu istemleri 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 almak demektir. Her taşıyıcı kombinasyonunun tüm hedef platformlarınızda nasıl davrandığını anlamalı ve kapsamlı testler yapmalısınız. Taşıyıcı manipülasyonu, kullanıcılar için geçerli bir kimlik doğrulama yolunun bulunmadığı kimlik doğrulama çıkmazları yaratabilir.

Avantajlar:

• Uyarlanmış Kullanıcı Deneyimi: Belirli bağlamlarda kullanıcıların hangi kimlik doğrulama seçeneklerini göreceğini tam olarak kontrol edin
• iOS boş dizi sorununu çözer: iOS'un hiçbirini sağlamadığı yerlerde taşıyıcıları açıkça tanımlar
• Bağlama duyarlı optimizasyon: Cihaz türüne göre kimlik doğrulama kullanıcı arayüzünü uyarlayın

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ı, taşıyıcı değerlerinden bağımsız olarak bazen seçenekleri gösterdiğini veya gizlediğini göstermektedir
• Kimlik doğrulama çıkmazları riski: Aşırı kısıtlayıcı taşıyıcı filtrelemesi, özellikle çapraz cihaz senaryolarında, kullanıcıların tamamen kimlik doğrulaması yapmasını engelleyebilir
• Spesifikasyondan sapar: Spesifikasyon önerilerinden uzaklaşarak gelecekteki platform değişiklikleriyle olası sorunlara neden olur
• 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 garipliklerini manuel olarak yönetmelidir
• Test ek yükü: Her optimizasyon kuralının tüm platform kombinasyonlarında doğrulanması gerekir

Şunlar için en iyisidir: Belirli kullanıcı deneyimi gereksinimleri olan tüketici uygulamaları, platforma özgü mantığı sürdürecek kaynaklara sahip ekipler, spesifikasyona kesin uyum yerine kolaylaştırılmış kimlik doğrulama akışlarını önceliklendiren senaryolar.

WebAuthn taşıyıcı yönetimi tek başına var olmaz; bu, genel geçiş anahtarı uygulama stratejinizin bir parçasıdır. Her biri internal ve hybrid taşıyıcı kullanımı için farklı etkilere sahip olan üretim dağıtımlarında iki yaygın yaklaşım ortaya çıkmaktadır.

Bu yaklaşım esnekliğe ve standartlara uyumluluğa öncelik vererek, kullanıcıların uyumlu herhangi bir kimlik doğrulayıcı ile kimlik doğrulaması yapmasına olanak tanır.

Uygulama Özellikleri:

• Kimlik Doğrulama Kullanıcı Arayüzü: Geçiş anahtarı butonu, mevcut oturum açma seçeneklerinin (kullanıcı adı/şifre) yanında görünür
• allowCredentials: Herhangi bir kimlik bilgisinin eşleşmesine izin veren boş dizi [] olarak ayarlanır
• Kimlik doğrulayıcı türleri: Güvenlik anahtarları, çapraz cihaz kimlik doğrulaması (QR kodları), platform kimlik doğrulayıcılarının tümü desteklenir
• Yerel uygulama gereksinimleri: Güvenlik anahtarları dahil tüm kimlik doğrulama yöntemlerini desteklemelidir
• preferImmediatelyAvailableCredentials: Tanımı gereği güvenlik anahtarlarını ve QR kod oturum açmalarını hariç tuttuğu için kullanılamaz
• Taşıyıcı yönetimi: Güvenlik anahtarı taşıyıcıları (usb, nfc, ble) dahil tüm taşıyıcı türlerini kapsamalıdır

Taşıyıcı Etkileri:

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

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

Bu yaklaşım, geçiş anahtarı oluşturmayı platform kimlik doğrulayıcıları ile sınırlandırarak ve önce tanımlayıcı akışlarını (identifier-first flows) kullanarak tüketici UX'i için optimize eder.

Uygulama Özellikleri:

• Geçiş anahtarı oluşturma: Kullanıcı tarafından başlatılan teşvikler (oturum açma sonrası istemler, otomatik oluşturma akışları), hemen kullanılabilecek kimlik doğrulayıcılara odaklanmak için authenticatorAttachment: "platform" kullanır
• Güvenlik anahtarı desteği: Uzman kullanıcıların güvenlik anahtarları dahil herhangi bir kimlik doğrulayıcı seçmesine olanak tanıyan authenticatorAttachment kısıtlaması olmadan web hesap ayarlarında mevcuttur
• Kimlik doğrulama akışı: Önce tanımlayıcı (identifier-first); kullanıcılar kimlik doğrulamadan önce e-posta/kullanıcı adı girerler
• allowCredentials: Tanımlayıcı bilindiğinde kullanıcının belirli kimlik bilgileriyle doldurulur (boş değil)
• Kimlik doğrulayıcı türleri: Platform kimlik doğrulayıcıları ve çapraz cihaz kimlik doğrulaması önceliklidir; güvenlik anahtarları desteklenir ancak birincil akışlarda teşvik edilmez
• Yerel uygulama optimizasyonu: Güvenlik anahtarları veya QR kodları için istemler olmadan sessiz, anında kimlik doğrulaması için preferImmediatelyAvailableCredentials kullanır
• Çapraz cihaz kimlik doğrulaması: Web'de mevcuttur; preferImmediatelyAvailableCredentials kullanıldığında yerel uygulamalarda bilinçli olarak hariç tutulur (kullanıcılar genellikle geçiş anahtarlarının bulunduğu cihazda kimlik doğrulaması yapar)
• Taşıyıcı yönetimi: Birincil odak internal ve hybrid taşıyıcılardır

Taşıyıcı Etkileri:

allowCredentials belirli kimlik bilgilerini taşıyıcılarıyla birlikte içerdiğinden, kimlik doğrulama deneyimlerini optimize etmek için taşıyıcı yönetimi kritik hale gelir.

Güvenlik Anahtarı Gerçeği: Güvenlik anahtarları, büyük ölçekli tüketici dağıtımlarında geçiş anahtarı kullanımının son derece küçük bir bölümünü, öncelikle uzman kullanıcıları veya belirli güvenlik gereksinimleri olan kullanıcıları temsil eder. Tüketiciye uyarlanmış yaklaşım, birincil akışları bunlar etrafında optimize etmeden güvenlik anahtarlarını destekleyerek bu gerçeği kabul eder.

İki Kademeli Oluşturma Stratejisi: Uygulamalar, ikili oluşturma yolları aracılığıyla güvenlik anahtarı uyumluluğunu optimize edilmiş tüketici UX'i ile dengeleyebilir:

• Kullanıcı teşvikleri ve istemler: Oturum açma sonrası istemler ve otomatik oluşturma akışları, authenticatorAttachment: "platform" kullanarak kullanıcıları yüksek başarı oranlarıyla anında kullanılabilecek geçiş anahtarlarına yönlendirir
• Web hesap ayarları: Uzman kullanıcıların güvenlik anahtarlarını, üçüncü taraf şifre yöneticilerini veya mevcut herhangi bir kimlik doğrulayıcıyı seçmesine olanak tanıyarak authenticatorAttachment olmadan oluşturma sunar

Bu kalıp büyük uygulamalarda ortaya çıkar: güvenlik anahtarları ayarlar aracılığıyla desteklenir ve işlevseldir, ancak kullanıcıya yönelik teşvikler baskın kullanım senaryosu (anında, sessiz kimlik doğrulaması sağlayan platform kimlik doğrulayıcıları) için optimize eder.

Şunlar için en iyisidir: Tüketici uygulamaları, yerel mobil uygulamalar, kimlik doğrulayıcı esnekliğinden ziyade kolaylaştırılmış UX'i önceliklendiren senaryolar, önce tanımlayıcı akışlarının zaten mevcut olduğu platformlar.

Halihazırda hesap varlığını sızdıran veya önce tanımlayıcı akışları kullanan (kullanıcının oturum açma seçeneklerini görmeden önce e-posta girdiği) platformlar için, tüketiciye uyarlanmış yaklaşım doğal olarak uyum sağlar. Kullanıcı tanımlayıcısını sağladığında:

1. Arka uç mevcut geçiş anahtarlarını sorgular
2. Belirli kimlik bilgileri ve bunların taşıyıcılarıyla birlikte allowCredentials döndürür
3. Platform kimlik doğrulama kullanıcı arayüzünü taşıyıcılara göre optimize edebilir
4. Ek bir hesap numaralandırma riski (account enumeration risk) yoktur (tanımlayıcı zaten sağlanmıştır)

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

Öneri: Zaten önce tanımlayıcı akışlarını kullanan veya hesap numaralandırmanın bir endişe kaynağı olmadığı platformlar için, açık taşıyıcı yönetimi içeren tüketiciye uyarlanmış yaklaşım, özellikle preferImmediatelyAvailableCredentials'ın kesintisiz biyometrik kimlik doğrulamasını mümkün kıldığı yerel mobil uygulamalarda üstün UX sağlar.

Internal ve hybrid taşıyıcıları işlemek için hangi yaklaşımı seçerseniz seçin, sorunları en aza indirmek için bu uygulamaları izleyin:

Kayıt Sırasında Taşıyıcıları Kaydedin: Kimlik doğrulayıcı yanıtından gelen transports dizisini her zaman kimlik bilgisi kimliği (ID) ve ortak anahtarla (public key) birlikte saklayın. Bu veri, kimlik doğrulama akışları için önemlidir.

Boş Dizileri Zarif Bir Şekilde İşleyin: iOS platform kimlik doğrulayıcılarından boş bir taşıyıcı dizisi alırken:

• Spesifikasyon uyumlu: Boş bırakın veya taşıyıcı özelliğini atlayın; taşıyıcı bilgisinin kullanılamadığını gösterir; platformlar mevcut seçenekleri belirleyecektir
• Optimizasyon yaklaşımı: Hangi kimlik doğrulama seçeneklerinin gösterileceğini kontrol etmek için ["internal", "hybrid"] ile doldurun

Web ve Yerel Taşıyıcı Stratejileri: Taşıyıcı yönetimini bağlama göre farklılaştırın:

• Web kimlik doğrulaması: USB/NFC aracılığıyla güvenlik anahtarları dahil olmak üzere daha geniş kimlik doğrulayıcı desteğine izin vererek tüm taşıyıcıları dahil edin
• Yerel uygulama kimlik doğrulaması: Sessiz kimlik doğrulaması için preferImmediatelyAvailableCredentials kullanın; taşıyıcılar kaydedildiği gibi gönderilir
• Ayarlar/yönetim sayfaları: Uzman kullanıcılar için tüm kimlik doğrulayıcı türlerini destekleyin

Güvenlik Anahtarı Kimlik Doğrulamasını Yönetin: Kullanıcıların kayıtlı güvenlik anahtarları olduğunda:

• Web: Saklanan kimlik bilgilerindeki güvenlik anahtarı taşıyıcılarını algılayın ve kimlik doğrulama akışlarının bunlara uyum sağlayabildiğinden emin olun
• Yerel uygulamalar: Yedek kimlik doğrulama yöntemleri sağlamayı veya güvenlik anahtarı kimlik doğrulaması için kullanıcıları web'e yönlendirmeyi düşünün
• Hibrit yaklaşım: Yerel uygulamalar platform kimlik doğrulayıcıları için optimize ederken web tam kimlik doğrulayıcı esnekliğini destekler

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

• Kayıt: Web, iOS Yerel, Android Yerel
• Kimlik Doğrulama: Web, iOS Yerel, Android Yerel
• Sessiz kimlik doğrulamasının preferImmediatelyAvailableCredentials ile çalıştığını doğrulayın
• Güvenlik anahtarlarının authenticatorAttachment olmadan ayar akışlarında çalıştığını onaylayın
• QR kodlarının yalnızca uygun bağlamlarda göründüğünü doğrulayın

Taşıyıcı Semantiğini Anlayın: Boş ve eksik taşıyıcı değerleri arasındaki farkları tanıyın:

• Boş taşıyıcılar dizisi []: Taşıyıcı bilgisinin kullanılamadığını veya gizlilik için saklandığını gösterir. Kullanıcı aracıları (user agents) taşıyıcı yeteneklerini bildiremediklerinde veya bildirmemeyi seçtiklerinde boş diziler sağlayabilirler. Bu "tüm taşıyıcılar destekleniyor" ile eşdeğer değildir; bilginin kullanılamadığı durumlarda ipucu olarak ele alın.
• Eksik taşıyıcı özelliği: Taşıyıcılar (transports) kimlik bilgisi tanımlayıcılarından atlandığında, kullanıcı aracıları diğer faktörlere dayanarak mevcut kimlik doğrulama yöntemlerini belirler. Bağlam önemlidir: kayıt yanıtlarında kimlik doğrulama isteği seçeneklerine karşı etkiler farklılık gösterir.
• Taşıyıcı ipuçları: Spesifikasyona göre taşıyıcılar, yeteneklerin yetkili garantileri olarak değil, kullanıcı aracılarının kimlik doğrulama kullanıcı arayüzünü optimize etmelerine yardımcı olacak ipuçları olarak ele alınmalıdır.

Platform Değişikliklerini İzleyin: WebAuthn uygulamaları gelişiyor. Apple, Google ve Microsoft, kimlik 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 internal ve hybrid taşıyıcılar, çapraz cihaz kimlik doğrulamasında önemli pratik etkiye sahip teknik detaylardır. Taşıyıcı yönetim stratejiniz, daha geniş geçiş anahtarı uygulama yaklaşımınız ve hedef platformlarınızla uyumlu olmalıdır.

Taşıyıcı Kararları Daha Geniş Bir Strateji İçinde Yaşar: Taşıyıcıları nasıl ele alacağınız, maksimum esneklik (boş allowCredentials) veya tüketici UX'i (belirli kimlik bilgileriyle önce tanımlayıcı) için mi geliştirdiğinize bağlıdır. İkincisi, taşıyıcıları optimizasyon için kritik hale getirir.

Platform Farklılıkları Müdahale Gerektirir: Web ve Android güvenilir taşıyıcı bilgisi sağlarken, iOS platform kimlik 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ı: Spesifikasyon uyumlu (kimlik 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ı ve yerel mobil uygulamalara sahip tüketici uygulamalarına uygundur.

Önce Tanımlayıcı, Taşıyıcı Optimizasyonunu Mümkün Kılar: Kullanıcılar tanımlayıcılarını önce sağladıklarında, taşıyıcı yönetimi güçlü bir UX aracı haline gelir. Ek hesap numaralandırma endişeleri olmadan, mobilde istenmeyen QR kodlarını önleyebilir, güvenlik anahtarı seçeneklerini gizleyebilir ve kimlik doğrulamayı kolaylaştırabilirsiniz.

Kurumsal / Maksimum Esneklik İçin:

• Tüm kimlik doğrulayıcı türlerini desteklemek için boş allowCredentials kullanın
• Kimlik 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öreceğini kabul edin
• Daha basit uygulama, daha geniş uyumluluk

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

• Önce tanımlayıcı (identifier-first) kimlik doğrulama akışı uygulayın
• Kullanıcı teşvikleri (oturum açma sonrası, otomatik istemler): Yüksek başarılı anında kimlik doğrulaması için authenticatorAttachment: "platform" kullanın
• Web hesap ayarları: Güvenlik anahtarlarına ihtiyaç duyan uzman kullanıcılar için authenticatorAttachment olmadan oluşturmaya izin verin
• Belirli kimlik bilgileri ve optimize edilmiş taşıyıcılarla allowCredentials kullanın
• Yerel uygulamalar: Sessiz kimlik doğrulaması için preferImmediatelyAvailableCredentials'ı etkinleştirin
• iOS boş dizilerini ["hybrid", "internal"] ile doldurun
• Web kimlik doğrulaması: Güvenlik anahtarları dahil tüm taşıyıcıları destekleyin
• QR kodlarını uygun olan yerlerde önlemek için mobil cihazlarda hybrid'i filtreleyin
• Uyumluluğu korurken kolaylaştırılmış kimlik doğrulama seçenekleriyle üstün UX

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

• Hesap numaralandırma (Account enumeration) zaten bir sorun değildir
• Tüketiciye uyarlanmış yaklaşım mevcut UX ile doğal olarak uyum sağlar
• Taşıyıcı optimizasyonu anında UX avantajları sağlar
• Çoğu tüketici uygulaması için önerilen yaklaşımdır

Spesifikasyon uyumlu başlayın, ardından stratejinize göre optimize edin:

1. Kayıt sırasında taşıyıcıları tam olarak alındığı gibi kaydedin
2. Genel stratejinize karar verin (maksimum esneklik vs. tüketiciye uyarlanmış)
3. Tüketiciye uyarlanmışsa: önce tanımlayıcı akışını uygulayın ve taşıyıcıları optimize edin
4. Seçtiğiniz strateji için iOS boş dizilerini uygun şekilde işleyin
5. Web, iOS Yerel ve Android Yerel platformlarında kapsamlı bir şekilde test edin

WebAuthn ortamı gelişmeye devam ediyor. Platform satıcıları uygulamalarını düzenli olarak günceller ve WebAuthn Level 3 gibi spesifikasyonlar yeni yetenekler sunar. Taşıyıcı yönetimini daha geniş kimlik doğrulama stratejinizle hizalayan esnek sistemler oluşturmak, geçiş anahtarı uygulamanızın sağlam kalmasını ve ekosistem olgunlaştıkça mükemmel kullanıcı deneyimleri sağlamasını garanti eder.

Corbado Hakkında

Corbado, büyük ölçekte tüketici kimlik doğrulaması yöneten CIAM ekipleri için Passkey Intelligence Platform'tur. IDP loglarının ve genel analytics araçlarının göremediğini görmenizi sağlarız: hangi cihazların, OS sürümlerinin, tarayıcıların ve credential manager'ların passkey desteklediğini; kayıtların neden girişe dönüşmediğini; WebAuthn akışının nerede başarısız olduğunu; bir OS ya da tarayıcı güncellemesinin girişi sessizce ne zaman bozduğunu — hem de Okta, Auth0, Ping, Cognito veya kendi IDP'nizi değiştirmeden. İki ürün: Corbado Observe, passkey'ler ve diğer tüm giriş yöntemleri için observability sağlar. Corbado Connect, analytics entegre managed passkey'ler sunar (IDP'nizin yanında). VicRoads, Corbado ile 5M+ kullanıcı için passkey çalıştırıyor (%80+ passkey aktivasyonu). Bir Passkey uzmanıyla görüşün →

iOS AuthenticationServices, iCloud Keychain gibi platform kimlik doğrulayıcıları için taşıyıcı bilgilerini saklar ve WebAuthn spesifikasyonunun gizlilik hükümlerine göre boş diziler döndürür. iOS'taki güvenlik anahtarları ["usb"] veya ["nfc"] gibi taşıyıcı verileri sağlar. Bağlı taraflar (relying parties), tüm taşıyıcıları yeteneklerin kesin bir garantisi olmaktan ziyade ipuçları olarak ele almalıdır.

cable, caBLE (cloud-assisted Bluetooth Low Energy) anlamına gelen, hybrid ile eş anlamlı eski bir terminolojidir. Her ikisi de, bir telefon kullanarak masaüstü oturumunun kimliğini doğrulamak için QR kodu taramak gibi çapraz cihaz kimlik doğrulamasını tanımlar. hybrid, WebAuthn Level 3'te tanıtılan güncel terimdir ve yeni uygulamalarda kullanılmalıdır.

Önce tanımlayıcı (identifier-first) akışları kullanan tüketici uygulamaları için, kayıt sırasında boş diziler döndüren iOS platform kimlik doğrulayıcılarında taşıyıcıları açıkça ["hybrid", "internal"] olarak ayarlayın. Bu, USB ve NFC güvenlik anahtarı istemlerinin kimlik doğrulama kullanıcı arayüzünde görünmesini engeller. Spesifikasyon uyumlu alternatif ise dizileri boş bırakmak veya transports özelliğini tamamen atlamaktır.

Mobilde hybrid taşıyıcının kaldırılması, kullanıcılar halihazırda geçiş anahtarlarının bulunduğu bir cihazdayken QR kodu istemlerinin çıkmasını engeller. Ancak taşıyıcı manipülasyonu tutarsız sonuçlar üretir: bazı platformlar hybrid hariç tutulduğunda bile QR kodlarını gösterirken, diğerleri ne olursa olsun bunları gizler. Çıkmaz sokaklar (deadends) yaratmaktan kaçınmak için her zaman hedef platformlarda test yapın ve yedek kimlik doğrulama yöntemleri sağlayın.

Boş bir allowCredentials dizisi, güvenlik anahtarları ve çapraz cihaz kimlik doğrulaması dahil tüm kimlik doğrulayıcı türlerini destekler, ancak taşıyıcı alaka düzeyini azaltır ve kullanıcılara aynı anda birden fazla seçenek sunabilir. Bunu belirli kullanıcı kimlik bilgileriyle doldurmak, taşıyıcı yönetimini kullanıcı arayüzünü optimize etmek için kritik hale getirir; bu da, tüketici bağlamlarında güvenlik anahtarı istemlerini gizlemek ve mobilde QR kodlarını filtrelemek için önce tanımlayıcı akışlarına (identifier-first flows) olanak tanır.