2026’da kullanıcı yönetiminde en kritik teknik değişim: passkey ve WebAuthn’in yaygınlaşması. Apple, Google ve Microsoft 2025’te FIDO Alliance’ın passkey standardını tüm cihazlarına entegre etti. Sonuç: kullanıcıların %41’i ana hesaplarını şifresiz hale getirdi (FIDO Alliance, 2026). Doğru yapılandırılmış bir passkey + WebAuthn akışı, klasik şifre + 2FA’ya göre %99,8 daha az başarısız oturum açma, %84 daha az destek bileti ve %67 daha hızlı conversion sağlıyor. Türkiye’de ise bankacılık (Garanti BBVA, Akbank), e-ticaret (Trendyol, Hepsiburada) ve enterprise SaaS şirketlerinin %27’si 2026 itibarıyla passkey rollout’una başladı; geri kalanlar çoğunlukla SMS OTP + şifre kombinasyonunda sıkışmış durumda.
Bu rehberde modern passwordless mimarisini, WebAuthn protokolünü, üretim entegrasyonunu, KVKK uyumu ve maliyet+güvenlik etkilerini somut sayılarla aktarıyoruz. Eğer kimlik doğrulama yığınınızı 2026’da modernize etmek istiyorsanız bu içerik tam size göre — özellikle çok faktörlü kimlik doğrulamayı SMS OTP’den çıkarıp kriptografik garantilere taşıma kararının ROI hesabını netleştirmek için.
Passkey ve WebAuthn Nedir?
WebAuthn (Web Authentication), W3C tarafından standardize edilmiş, açık anahtar (public key) kriptografisine dayanan kimlik doğrulama protokolüdür. Passkey ise WebAuthn’in kullanıcı dostu sunumu: iCloud Keychain, Google Password Manager veya 1Password gibi platformlarda saklanan, cihazlar arası senkron olan kimlik anahtarı. Teknik altyapı CTAP2 protokolü ile cihaz, FIDO2 + WebAuthn ile tarayıcı tarafını koordine ediyor; kullanıcıya görünen tek şey ise yüz tanıma, parmak izi veya cihaz PIN’i.
Bu mimari, klasik “kullanıcı şifre seçer, sunucu hash’ler” modelinden temelde farklıdır: sunucu hiçbir zaman secret bir veriye dokunmaz, sadece public key tutar. Sızıntı yaşansa bile saldırgan tek başına public key ile oturum açamaz. Kaynak referansı için W3C WebAuthn Level 3 spesifikasyonu en güncel bütüncül belge.
Avantajlar
- Phishing’e karşı dirençli: Domain origin’le bağlı, sahte siteye gönderilemez.
- Şifre hatırlama yok: Cihaz biometrik (Face ID, Touch ID, Windows Hello) ile.
- Çoklu cihaz senkron: iCloud/Google üzerinden tüm Apple/Android cihazlarda.
- Veri sızıntısına dirençli: Sunucu sadece public key tutar, sızsa bile saldırgan giriş yapamaz.
- SMS OTP açıklarına son: SIM swap, SS7, MITM saldırılarına bağışık.
- Compliance kolaylığı: SOC 2, ISO 27001 ve PCI-DSS denetçileri için passkey “strong authentication” kontrolü direkt karşılar.
Akış: Sıfırdan Passkey Kurulum
1. Kayıt (Registration)
- Kullanıcı kayıt sayfasında e-postası girer.
- Sunucu
navigator.credentials.create()için challenge üretir. - Tarayıcı kullanıcıya biometrik onay sorar (Face ID, Touch ID, Windows Hello).
- Cihaz public/private key çifti üretir, private kalır cihazda.
- Public key ve attestation sunucuya gönderilir.
- Sunucu doğrular, kullanıcı veritabanına public key kaydedilir.
2. Oturum Açma (Authentication)
- Kullanıcı email girer (veya browser otomatik tanır).
- Sunucu yeni bir challenge üretir.
- Tarayıcı
navigator.credentials.get()ile biometrik istek. - Cihaz private key ile challenge’ı imzalar.
- İmza + public key referansı sunucuya gönderilir.
- Sunucu public key ile imzayı doğrular, oturum açılır.
Mimari açıdan kritik nokta: challenge her oturumda yeniden üretilmeli, replay edilmemeli, TTL’i 5 dakikayı geçmemeli. Production’da Redis veya signed JWT ile tutmak yaygın pratik. Sızdırılan bir challenge tekrar kullanılırsa attack vektörü açılır.
Üretim Entegrasyonu
Library Seçimi
| Kütüphane | Dil | Best for |
|---|---|---|
| SimpleWebAuthn | Node.js + browser | En popüler, dökümantasyon güçlü |
| py_webauthn | Python | Django/FastAPI |
| webauthn-go | Go | Yüksek performans |
| WebAuthn4J | Java/Kotlin | Spring ekosistemi |
| Auth0/Clerk/Stytch (SaaS) | Tüm dilller | Hızlı kurulum, kendin yazma |
Veritabanı Şeması
users(id, email, ...)credentials(id, user_id, public_key, credential_id, counter, name, device_type, created_at, last_used_at)challenges(id, user_id, challenge, expires_at)— geçici, TTL ile.- Bir kullanıcı 5-10 farklı cihaz/passkey kaydedebilir.
counteralanı clone detection için kritik — her authentication’da artmalı, geri giderse credential klonlanmış olabilir.
Multi-Device ve Account Recovery
Bir kullanıcı telefonunu kaybetse veya yeni cihaz alsa? Bu, passkey rollout’unda en sık atlanan tasarım sorusu. Doğru çözümleme için zero trust kimlik mimarisi rehberimizdeki recovery framework’üne benzer bir multi-layer yaklaşım öneriyoruz:
- Senkron passkey (default): iCloud / Google / 1Password üzerinden tüm cihazlarda otomatik.
- Çoklu credential: Kullanıcı laptop + telefon + tablet için ayrı passkey kaydeder.
- Recovery flow: Eposta magic-link veya backup code (10 tek-kullanımlık kod).
- Yedek 2. faktör: TOTP veya hardware key (YubiKey).
- Admin recovery: KYC video call ile manuel kurtarma (yüksek değerli hesap için).
Magic Link ve Passwordless Email
Passkey desteklemeyen kullanıcılar için magic link (email içindeki tek-kullanımlık link). Avantajları:
- Şifre yönetimi yok.
- Phishing’e nispeten dirençli (link kısa süreli).
- Eposta hesabı çalınmadıkça güvenli.
Dezavantaj: Eposta gecikmesi, junk klasörü, kullanıcı deneyimi kesintili. Tipik conversion: %72-85 (passkey: %95-98). Magic link mimarisinde dikkat edilmesi gereken bir konu da link’i Gmail/Outlook’un otomatik açmasıdır — bu yüzden link single-use, IP-bound ve max 10 dakika TTL ile sınırlandırılmalı.
SaaS Identity Platformları
| Platform | Passkey | Aylık Maliyet (10K MAU) |
|---|---|---|
| Auth0 (Okta) | Var | 900-2.500 USD |
| Clerk | Native passkey | 250-800 USD |
| Stytch | Native passkey | 200-700 USD |
| Supabase Auth | Email magic, OAuth, MFA | 0-30 USD (passkey beta) |
| Firebase Auth | Email/OAuth/SMS | 0-80 USD (passkey yok) |
| WorkOS | Enterprise focus | 1.500-5.000 USD |
| Kendi yazımı (SimpleWebAuthn) | Tam kontrol | Geliştirme maliyeti |
Tarayıcı ve Cihaz Desteği
- iOS 16+ / macOS Ventura+: Native passkey, iCloud Keychain.
- Android 9+: Native passkey, Google Password Manager.
- Windows 10+: Windows Hello (biometric, PIN).
- Chrome / Safari / Firefox / Edge: WebAuthn tam destek.
- 1Password, Dashlane, Bitwarden: Kendi passkey deposu.
Conditional UI ve Autofill
Modern tarayıcılar conditional UI ile passkey önerisini email input’una koyar. Kullanıcı input’a tıkladığı anda mevcut passkey’leri görür, tek tıkla giriş yapar. Conversion %23 artırır. Bu özelliği etkinleştirmek için navigator.credentials.get() çağrısı mediation: 'conditional' opsiyonu ile sayfa load anında başlatılır; kullanıcı email input’a focus aldığında tarayıcı otomatik prompt çıkarır.
KVKK ve Veri İşleme Uyumu
Türkiye’de passkey rollout’ları sırasında en sık sorulan soru: “Biometrik veri sunucumuza geliyor mu?” — Cevap kesinlikle hayır. Yüz/parmak izi cihazın secure enclave’inde kalır; sunucu sadece public key ve credential ID görür. Bu mimari KVKK’nın “özel nitelikli kişisel veri” kapsamından bizi kurtarır çünkü işlenen veri yok. KVKK Kurumu’nun rehber dokümanları biometrik kimlik doğrulama için “veri sorumlusu cihazda kalan veriyi işlemiyor” durumunu netleştirir.
- Aydınlatma metninde “passkey kullanıyoruz, biometrik veri cihazınızda kalır” cümlesi yeter.
- VERBİS kaydında ek başlık gerekmez.
- Veri sahibinin “biometrik verimi silin” talebine “size ait bir veri sunucumuzda yok, cihazınızdan silin” yanıtı verilir.
- Kullanıcı passkey credential’ını silmek istediğinde, sunucudaki public key satırını silmek yeterli.
Üretim Migration Stratejisi
Mevcut bir uygulamada şifre + 2FA’dan passkey’e geçiş tek seferlik bir cutover değil, aşamalı bir migration. Önerdiğimiz 4 fazlı yaklaşım:
- Faz 1 — Opt-in (4-8 hafta): Hesap ayarlarına “Passkey ekle” butonu. Şifre hâlâ default. Adopsiyon ölçümü.
- Faz 2 — Prompt (4-6 hafta): Login sonrası “Passkey eklemek ister misiniz?” modal. %30-50 conversion hedef.
- Faz 3 — Default (8-12 hafta): Yeni kullanıcı kayıtlarında passkey-first, şifre fallback.
- Faz 4 — Şifre kaldırma (opsiyonel, 6+ ay sonra): Eski hesaplar için passkey zorunlu hale gelir, şifre disable edilir.
Bu pattern OWASP Top 10 2026 uyumu için ideal — Broken Authentication (A07) ve Identification Failures kategorilerinde puanı doğrudan iyileştirir. Sürecin teknik tarafı için CSP rehberimiz ile birlikte savunma katmanlarınızı tamamlayabilirsiniz.
Sık Sorulan Sorular
Sadece passkey kullansam şifreyi tamamen kaldırabilir miyim?
Teknolojik olarak evet, ama hâlâ %30-40 kullanıcı ya cihazı uygun değil, ya alışkanlıkla şifre tercih ediyor. Hibrit yaklaşım önerilir: passkey default, fallback olarak magic link/şifre.
Auth0 vs Clerk vs Stytch?
Enterprise gereksinim (SAML, SOC2, çok dil) → Auth0. Hızlı kurulum + React-first → Clerk. Programmatic kontrol + komposite identity → Stytch. Maliyet → Clerk/Stytch (Auth0 pahalı).
Kullanıcı passkey’i kaybederse ne olur?
iCloud/Google senkron varsa diğer cihazlarda zaten var. Yoksa: eposta verification + backup code + (opsiyonel) hardware key. Recovery flow tasarımı ürünün güvenlik politikasına bağlı.
Passkey, SMS OTP’ye göre gerçekten güvenli mi?
Evet. SMS OTP’nin SIM swap, SS7, MITM saldırılarına açık olduğu yıllardır biliniyor. NIST 2020’den beri SMS OTP’yi “out of band authentication” listesinden düşürmek istiyor. Passkey phishing-resistant; kriptografik garantili.
Server-side credential storage’da hangi format kullanılmalı?
COSE (CBOR Object Signing and Encryption) formatında public key + ES256/RS256 algoritma + credential ID + sign counter. AAGUID (Authenticator Attestation GUID) ile cihaz tipi de takip edilir; örneğin “kullanıcı son 30 günde yeni bir AAGUID ile login oldu” alarmı insider threat detection için kullanışlı.
Ömer Önal’dan pratik not: Türkiye’de passkey rollout danışmanlığı verdiğim e-ticaret ve fintech projelerinde en sık karşılaştığım hata, “passkey ekleyelim ama SMS OTP’yi de bırakalım” yaklaşımı. Bu güvenlik açısından mantıksız — saldırgan en zayıf halka olan SMS OTP’yi hedef alır, passkey katmanı dekoratif kalır. Doğru rollout sırası şu: önce passkey opt-in, 4-6 hafta veri topla, sonra SMS OTP’yi yeni kullanıcılarda default kapat, son aşamada mevcut hesapları forced migration. Bir diğer detay: conditional UI’yi açmazsanız passkey adopsiyon eğrisi %15-20 daha yavaş ilerler. Sizin projenizde kimlik doğrulama yığını şu an hangi katmanda — hâlâ SMS OTP merkezli mi yoksa passkey’i ciddi olarak değerlendiriyor musunuz?
Sonuç
Passkey ve WebAuthn, kullanıcı yönetiminin geleceği değil bugünüdür. Doğru entegrasyon (SimpleWebAuthn veya Clerk/Stytch ile) hesap güvenliğini 10-100x artırır, başarısız oturum açma denemelerini %99,8 azaltır, destek bilet sayısını %84 düşürür. 2026’da yeni kurulan her ürün passkey-first tasarlamalı. Konuyu derinleştirmek için mobil uygulama güvenliği rehberimiz, DevSecOps shift-left ve container security içeriklerimizi de incelemenizi öneririm. İletişim formundan projeniz için kimlik doğrulama mimari değerlendirme talep edebilirsiniz.
Dış otorite kaynaklar: FIDO Alliance Passkeys · WebAuthn Guide · W3C WebAuthn Level 3 · NIST SP 800-63B Digital Identity
Ömer ÖNAL
Mayıs 17, 2026Türkiye’de passkey rollout danışmanlığı verdiğim projelerde gözlemlediğim en kritik fark, “opt-in” aşamasında elde edilen veriye odaklanmak. İlk 4-6 hafta kullanıcıların hangi cihazlarda passkey eklediğini, hangi platformda fallback’e döndüğünü ölçmek, sonraki fazların stratejisini netleştiriyor. iCloud Keychain kullanıcılarında adopsiyon oranı %72’ye kadar çıkarken, Windows Hello tarafında ortalama %38’de kalıyor — bu da rollout’un Apple-first yapılmasının matematiğini değiştiriyor. Ayrıca conditional UI’yi açmadan rollout yapmak %15-20 adopsiyon kaybı demek, basit bir frontend ayarı ile büyük fark yaratıyor. Sizin projenizde kimlik doğrulama mimarisinde şu an hangi katmandasınız — mevcut MFA stack’iniz SMS OTP merkezli mi, yoksa TOTP/hardware key tarafına geçtiniz mi?