---
url: 'https://www.corbado.com/tr/blog/webauthn-transports-dahili-hibrit'
title: 'WebAuthn Taşıyıcıları: Internal ve Hybrid Taşıyıcı'
description: 'Çapraz cihaz geçiş anahtarı kimlik doğrulaması için WebAuthn taşıyıcılarının tarayıcı API''lerinde, iOS AuthenticationServices ve Android Credential Manager''da nasıl çalıştığını keşfedin.'
lang: 'tr'
author: 'Vincent Delitz'
date: '2025-10-31T14:40:26.174Z'
lastModified: '2026-08-29T06:06:32.878Z'
keywords: 'webauthn taşıyıcıları, geçiş anahtarı, çapraz cihaz kimlik doğrulaması, internal taşıyıcı, hybrid taşıyıcı'
category: 'Passkeys Implementation'
---
# WebAuthn Taşıyıcıları: Internal ve Hybrid Taşıyıcı
### Platform Taşıyıcı İşleme: Hızlı Başvuru
| Platform | Platform Kimlik Doğrulayıcıları | Güvenlik Anahtarları |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | -------------------- |
| **Web Tarayıcıları** | Windows Hello: `["internal"]`
Google Password Manager: `["internal", "hybrid"]`
iCloud Keychain: `["internal", "hybrid"]` | `["usb", "nfc"]` |
| **Android Yerel** | `["internal", "hybrid"]` | `["usb", "nfc"]` |
| **iOS Yerel** | ⚠️ **Boş `[]`** (iCloud Keychain) | `["usb", "nfc"]` |
_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._
## Key Facts
- **WebAuthn taşıyıcıları** kimlik doğrulayıcı ile istemci arasındaki iletişimi tanımlar;
üretim ortamlarındaki dağıtımlarda `internal` ve `hybrid` hakimken, iOS platform kimlik
doğrulayıcıları benzersiz şekilde boş taşıyıcı dizileri döndürür.
- **iOS AuthenticationServices**, doğru taşıyıcı verileri bildiren web tarayıcıları ve
Android Credential Manager'ın aksine, iCloud Keychain platform kimlik doğrulayıcıları
için boş diziler `[]` döndürür.
- **Spesifikasyon uyumlu yaklaşım**, kimlik doğrulayıcı tarafından sağlanan taşıyıcılara
tam olarak alındığı gibi güvenir; optimizasyon yaklaşımı ise hangi kimlik doğrulama
kullanıcı arayüzü seçeneklerinin görüneceğini kontrol etmek için `internal` ve `hybrid`
değerlerini değiştirir.
- Üretimde `["internal", "hybrid"]` kalıpları en yaygın olanıdır; **donanım güvenlik
anahtarı** taşıyıcıları (`usb`, `nfc`) çok nadirdir, öncelikli olarak kurumsal veya
yüksek güvenlikli senaryolarda kullanılır.
- `hybrid` taşıyıcı aracılığıyla **Çapraz Cihaz Kimlik Doğrulama tamamlama oranı**, genel
olarak Windows web'de %60–78 ve macOS web'de %66–86 aralığındadır. Bu oran, önce
tanımlayıcı akışlarında alt bantta (Windows web'de %52–67, macOS web'de %59–76) ve aynı
cihaz teşvik bağlamlarında üst banttadır (Windows web'de %79–98, macOS web'de %83–98).
`hybrid` en yüksek maliyetli taşıyıcıdır ve buna göre yönlendirilmelidir (Corbado
Passkey Benchmark 2026, 2026 1. Çeyrek).
## 1. Giriş: Çapraz Cihaz Kimlik Doğrulaması için WebAuthn Taşıyıcıları
Platformlar arası [geçiş anahtarları](https://www.corbado.com/tr/glossary/cda)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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) ve yerel
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-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**
## 2. WebAuthn Taşıyıcılarını Anlamak: Internal, Hybrid ve Platform Kimlik Doğrulayıcıları
### 2.1 WebAuthn Taşıyıcı Türleri: Internal, Hybrid, USB, NFC, BLE ve Smart-Card
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](https://www.w3.org/TR/webauthn-3/#enum-transport) altı
taşıyıcı türü tanımlar:
**`usb`**: [YubiKey](https://www.corbado.com/glossary/yubikey)'ler veya diğer [FIDO2](https://www.corbado.com/glossary/fido2)
[güvenlik](https://www.corbado.com/tr/faq/kripto-gecis-anahtarlari) tokenleri gibi USB bağlantı noktaları
üzerinden bağlanan donanım [güvenlik](https://www.corbado.com/tr/faq/kripto-gecis-anahtarlari) 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](https://www.corbado.com/tr/faq/kripto-gecis-anahtarlari) anahtarlarını veya NFC
özellikli cihazlarını dokundurmalarına olanak tanır.
**`ble`**: Bluetooth Düşük [Enerji](https://www.corbado.com/passkeys-for-energy) üzerinden kimlik doğrulamayı
kolaylaştırarak harici kimlik doğrulayıcılarla kablosuz iletişim sağlar.
**`smart-card`**: [Akıllı kart](https://www.corbado.com/tr/glossary/akilli-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](https://www.corbado.com/blog/passkeys-prf-webauthn)'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](https://www.corbado.com/glossary/icloud-keychain),
PC'lerdeki [Windows Hello](https://www.corbado.com/glossary/windows-hello) veya
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) cihazlardaki
[Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) gibi. Bunlar platform
kimlik doğrulayıcılarıdır.
Bir [geçiş anahtarı oluşturuldu](https://www.corbado.com/tr/faq/passkeys-nasil-olusturulur)ğ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](https://www.corbado.com/tr/blog/revolut-passkeys-analizi) 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](https://www.corbado.com/tr/blog/revolut-passkeys-analizi)
yöntemlerini sunacağını belirlemesine yardımcı olur.
[Watch on YouTube](https://www.youtube.com/watch?v=V1Pc4Gl0xKc)
### 2.2 Platforma Özgü Davranış
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.
#### 2.2.1 Web Tarayıcıları
Tarayıcılar taşıyıcı bilgisini kimlik doğrulayıcılardan alır ve
[kimlik doğrulama](https://www.corbado.com/tr/blog/revolut-passkeys-analizi) 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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/how-to-use-google-password-manager)'ı
kullandığında, [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager)
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/glossary/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](https://w3c.github.io/webauthn/#sctn-issuing-cred-request-to-authenticator)
#### 2.2.2 Android Yerel Uygulamaları
Android'in
[Credential Manager API'si](https://developer.android.com/identity/sign-in/credential-manager)
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](https://developer.android.com/training/sign-in/passkeys)
#### 2.2.3 iOS Yerel Uygulamaları
[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) daha karmaşık bir durum sunar. Apple'ın
[AuthenticationServices çerçevesi](https://developer.apple.com/documentation/authenticationservices),
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](https://www.corbado.com/faq/is-face-id-passkey)
veya Touch ID ile doğrulanır):
[Geçiş anahtarı oluşturma](https://www.corbado.com/tr/blog/passkey-olusturma-en-iyi-uygulamalari) 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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) cihazlarıyla kullanıldıklarında taşıyıcı bilgisi
(ör. `["usb"]`, `["nfc"]`) sağlarlar.
**Dokümantasyon**:
[Apple AuthenticationServices](https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys)
### 2.3 Üretim Ortamlarında Taşıyıcı Dağılımı
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:
| Taşıyıcı Kalıbı | Sıklık | Kaynak |
| ------------------------ | ---------- | ------------------------------------------------------------------------------------------------------------ |
| `["internal", "hybrid"]` | Çok yaygın | Web ve yerelde bulut senkronizasyonlu kimlik bilgisi yöneticileri (iCloud Keychain, Google Password Manager) |
| `["hybrid", "internal"]` | Çok yaygın | Yukarıdakiyle aynı, sıralama varyasyonu |
| `[]` (boş dizi) | Çok yaygın | iOS yerel platform kimlik doğrulayıcıları |
| `["internal"]` | Yaygın | Windows Hello, cihaza bağlı kimlik doğrulayıcılar |
| `["internal", "cable"]` | Nadir | Hybrid için eski gösterim (cable = eski terminoloji) |
| `["nfc", "usb"]` | Çok nadir | Donanım güvenlik anahtarları |
| `["usb"]` | Çok nadir | Yalnızca USB güvenlik anahtarları |
| `["hybrid"]` | Çok nadir | Yalnızca hybrid yapılandırmalar |
**Önemli Çıkarımlar**:
**Platform kimlik doğrulayıcıları hakimdir**: [Geçiş anahtarları](https://www.corbado.com/tr/glossary/cda)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ı](https://www.corbado.com/tr/glossary/cda)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](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/passkey-benchmark-2026/cross-device-authentication),
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.
### 2.4 Kimlik Doğrulayıcıya Göre Taşıyıcı Varyasyonları
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:
#### Başlıca Kimlik Bilgisi Yöneticileri
**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ı)
#### Üçüncü Taraf Şifre Yöneticileri
**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](https://www.corbado.com/tr/blog/yerel-uygulama-passkeys) 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
#### Bu Varyasyonlar Neden Meydana Geliyor
**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.
## 3. WebAuthn Taşıyıcı İşlemeye Yönelik İki Yaklaşım
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.
### 3.1 Spesifikasyon Uyumlu Yaklaşım: Internal ve Hybrid Taşıyıcılara Güvenmek
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](https://www.corbado.com/tr/faq/passkeys-nasil-olusturulur)ğ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:
```json
{
"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](https://www.corbado.com/glossary/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.
### 3.2 Taşıyıcı Optimizasyon Yaklaşımı: Çapraz Cihaz Kimlik Doğrulaması için Internal ve Hybrid'i Kontrol Etmek
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:
#### 3.2.1 Kullanım Senaryosu 1: Güvenlik Anahtarı Seçeneklerini iOS Anahtarlarından Kaldırmak
**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.
```typescript
// 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ü.
#### 3.2.2 Kullanım Senaryosu 2: Mobil Cihazlarda QR Kodlarını Önlemek
**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.
```typescript
// 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.
#### 3.2.3 Önemli Hususlar
**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ı](https://www.w3.org/TR/webauthn-3/#enum-hints) 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.
### 3.3 WebAuthn Taşıyıcı Stratejisi: Platform Kimlik Doğrulayıcıları ve Çapraz Cihaz Kimlik Doğrulaması
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.
#### 3.3.1 Strateji 1: Maksimum Standart Uygunluğu ve Kullanıcı Özgürlüğü
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](https://www.corbado.com/tr/blog/passkey-giris-en-iyi-uygulamalar), 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](https://www.corbado.com/tr/blog/qr-kod-giris-kimlik-dogrulama) 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.
#### 3.3.2 Strateji 2: Tüketiciye Uyarlanmış Platform Kimlik Doğrulayıcıları
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.
#### 3.3.3 Karşılaştırma Matrisi
| Özellik | Standart Uygunluğu | Tüketiciye Uyarlanmış |
| ------------------------------ | ---------------------------------------------------- | ------------------------------------------------------------------------ |
| **allowCredentials** | Boş dizi | Kullanıcıya özel kimlik bilgileri |
| **Kimlik doğrulayıcı türleri** | Tümü (platform, güvenlik anahtarları, CDA) | Platform + CDA (birincil), güvenlik anahtarları (ayarlar aracılığıyla) |
| **Yerel uygulama API'si** | Standart WebAuthn | preferImmediatelyAvailableCredentials |
| **Güvenlik anahtarları** | Tüm akışlarda desteklenir | Ayarlar aracılığıyla desteklenir |
| **Taşıyıcı alaka düzeyi** | Düşük (boş izin listesi) | Yüksek (belirli kimlik bilgileri) |
| **Mobil QR kodları** | Görünebilir | Optimize edilerek kaldırılabilir |
| **Kullanıcı deneyimi** | Daha fazla seçenek, daha fazla karmaşıklık | Kolaylaştırılmış birincil akışlar, uzman kullanıcı seçenekleri mevcuttur |
| **Uygulama karmaşıklığı** | Daha Düşük | Daha Yüksek (bağlama duyarlı taşıyıcı mantığı) |
| **Tüketici sürtünmesi** | Daha yüksek (birden fazla kimlik doğrulama seçeneği) | Daha Düşük (baskın kullanım senaryoları için optimize edilmiştir) |
#### 3.3.4 Önce Tanımlayıcı Akışları ve Hesap Numaralandırma (Account Enumeration)
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.
## 4. WebAuthn Taşıyıcı Uygulaması En İyi Uygulamaları
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.
## 5. Sonuç: WebAuthn Taşıyıcı Stratejinizi Seçmek
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.
### 5.1 Önemli Çıkarımlar
**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](https://www.corbado.com/glossary/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.
### 5.2 Stratejinizi Seçmek
**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**
### 5.3 Uygulama Önerisi
**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](https://www.corbado.com/blog/passkeys-prf-webauthn) 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.
## Sıkça Sorulan Sorular
### Geçiş anahtarı kaydı sırasında iOS neden boş taşıyıcı dizileri döndürüyor?
iOS AuthenticationServices, [iCloud Keychain](https://www.corbado.com/glossary/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.
### WebAuthn'de `cable` ve `hybrid` taşıyıcı arasındaki fark nedir?
`cable`, caBLE (cloud-assisted Bluetooth Low [Energy](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/blog/passkeys-prf-webauthn)'te tanıtılan güncel terimdir ve yeni
uygulamalarda kullanılmalıdır.
### allowCredentials listemdeki iOS platform kimlik doğrulayıcılarından gelen boş taşıyıcı dizilerini nasıl doldurmalıyım?
Ö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.
### Mobil cihazlarda allowCredentials'dan hybrid taşıyıcıyı ne zaman filtrelemeliyim?
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.
### Geçiş anahtarı kimlik doğrulaması için boş bir allowCredentials dizisi kullanmak ile onu belirli kimlik bilgileriyle doldurmak arasındaki fark nedir?
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.