Bir web sitesine passkey eklemek, giriş formuna yeni bir düğme yerleştirmekten ibaret değildir. Tarayıcı WebAuthn çağrısını başlatır; fakat challenge üretimi, credential kaydı, açık anahtar doğrulaması, hesap eşleştirme, oturum açma, cihaz yönetimi ve hesap kurtarma sorumluluğu uygulamanın backend sisteminde kalır. Bu parçalar birlikte tasarlanmadığında çalışan bir demo elde edilebilir, ancak güvenli ve sürdürülebilir bir kimlik sistemi kurulmuş olmaz.
Doğru entegrasyonun amacı tüm kullanıcıları bir gecede şifresiz bırakmak değildir. İlk hedef, mevcut hesap sistemine passkey kaydı ve passkey ile giriş yeteneğini güvenli biçimde eklemek; ardından kullanıcıları ölçülebilir ve geri alınabilir aşamalarla yeni yönteme taşımaktır. Bu rehber, WebAuthn protokolünün iç ayrıntılarını tekrar anlatmak yerine gerçek bir web projesinde hangi bileşenlerin hazırlanması gerektiğine odaklanır.
Passkey entegrasyonundan önce hangi kararlar verilmelidir?
Uygulamaya başlamadan önce mevcut kimlik sisteminin haritası çıkarılmalıdır. Kullanıcılar e-posta ve şifreyle mi, telefon numarasıyla mı, sosyal girişle mi yoksa kurumsal kimlik sağlayıcısıyla mı oturum açıyor? Aynı hesap hem web hem mobil uygulamada kullanılıyor mu? Birden fazla alt domain veya ülke domaini var mı? Bu soruların cevapları RP ID, hesap eşleştirme ve geçiş planını doğrudan etkiler.
| Karar alanı | Netleştirilmesi gereken soru | Yanlış kararın sonucu |
|---|---|---|
| RP ID ve domain | Passkey hangi ana domain ve alt domainlerde kullanılacak? | Bir ortamda oluşturulan passkey diğer giriş ekranında çalışmayabilir. |
| Hesap tanımlayıcısı | Credential hangi kalıcı kullanıcı kaydıyla eşleştirilecek? | E-posta değişikliğinde passkey ile hesap ilişkisi kopabilir. |
| Geçiş modeli | Şifre ve passkey bir süre birlikte mi çalışacak? | Kullanıcılar desteklenmeyen cihazlarda hesap dışında kalabilir. |
| Doğrulama seviyesi | User verification hangi işlemlerde zorunlu olacak? | Ya gereksiz sürtünme oluşur ya da hassas işlemler yetersiz korunur. |
| Kurtarma yöntemi | Tüm passkey'ler kaybedilirse hesap nasıl geri alınacak? | Zayıf kurtarma süreci güçlü giriş yöntemini etkisiz hale getirebilir. |
| Mobil uygulama ilişkisi | Web ve mobil aynı hesap ve passkey kapsamını paylaşacak mı? | Platformlar arasında kopuk veya yinelenen kimlik kayıtları oluşabilir. |
RP ID seçimi özellikle erken yapılmalıdır. Passkey, oluşturulduğu RP ID kapsamına kriptografik olarak bağlanır. Giriş sayfası login.example.com, mağaza shop.example.com üzerindeyse ve iki alt domain aynı kimlik sistemini kullanacaksa daha geniş kapsamlı example.com RP ID'si değerlendirilebilir. web.dev, RP ID'nin domain tabanlı olduğunu ve daha geniş bir üst domain seçiminin ilgili alt domainlerde aynı passkey'in kullanılmasını sağlayabildiğini açıklar web.dev RP ID Rehberi.
Bu karar mevcut domain mimarisi, reverse proxy, test ortamları ve mobil uygulama planıyla birlikte alınmalıdır. Kimlik sistemi farklı servislerle konuşuyorsa API entegrasyon altyapısının challenge ve oturum sınırlarını da doğru biçimde koruması gerekir.
Passkey entegrasyonu için önerilen sistem mimarisi
Üretim ortamında passkey desteği dört temel katmanda ele alınabilir: mevcut kullanıcı hesabı sistemi, WebAuthn istemci katmanı, FIDO/WebAuthn sunucu katmanı ve credential veri deposu. Google'ın sunucu tarafı uygulama rehberi, istemci API'lerinin yalnızca tarayıcı ile passkey sağlayıcısı arasındaki iletişimi yönettiğini; kayıt ve doğrulamanın tamamlanması için sunucu tarafı işlevlerin ayrıca uygulanması gerektiğini belirtir Google Server-Side Passkey Guide.
| Katman | Sorumluluk | Örnek çıktı |
|---|---|---|
| Kimlik ve hesap servisi | Kullanıcı hesabını, durumunu, yetkisini ve güvenli oturumunu yönetir. | Kalıcı user ID ve aktif session |
| Challenge servisi | Kayıt ve giriş için tek kullanımlık, süreli ve işlemle ilişkili challenge üretir. | Kullanıcı ve işlem türüne bağlı challenge kaydı |
| WebAuthn frontend | Sunucu seçeneklerini alır, tarayıcı API'sini çağırır ve sonucu backend'e gönderir. | PublicKeyCredential yanıtı |
| FIDO sunucu kütüphanesi | Creation/request options üretir, binary dönüşümleri ve kriptografik kontrolleri yürütür. | Doğrulanmış registration veya authentication sonucu |
| Credential deposu | Credential ID, açık anahtar ve kullanıcı ilişkisini saklar. | Kullanıcı başına bir veya daha fazla passkey kaydı |
| Risk ve audit katmanı | Başarısız denemeleri, yeni credential eklemeyi, silmeyi ve kurtarmayı izler. | İşlem geçmişi ve güvenlik sinyalleri |
WebAuthn standardı ayrıntılı ve hata toleransı düşük olduğundan kriptografik doğrulama kodunu sıfırdan yazmak genellikle doğru başlangıç değildir. Google, güncel ve bakımı sürdürülen bir FIDO sunucu tarafı kütüphanesinden yararlanılmasını önerir. Kütüphane seçerken yalnız programlama diline değil; WebAuthn sürüm desteğine, düzenli güvenlik güncellemelerine, origin/RP ID doğrulamasına, attestation davranışına ve test araçlarına bakılmalıdır.
Passkey entegrasyonunda kütüphane kullanmak güvenlik sorumluluğunu ortadan kaldırmaz. RP ID, izin verilen origin'ler, challenge yaşam döngüsü, oturum ilişkisi ve hesap kurtarma politikası yine uygulama ekibinin kararıdır.
Veritabanı modeli nasıl hazırlanmalıdır?
Passkey kaydını doğrudan kullanıcı tablosundaki tek bir “public_key” alanına eklemek kısa vadede kolay görünür, ancak kullanıcıların birden fazla cihaz veya passkey sağlayıcısı kullanmasını engeller. Daha doğru model, kullanıcı ile credential arasında bire-çok ilişki kuran ayrı bir tablodur. Böylece kullanıcı telefonundaki senkronize passkey'e ek olarak dizüstü bilgisayarında veya fiziksel güvenlik anahtarında başka bir credential kaydedebilir.
| Alan | Neden gerekir? | Uygulama notu |
|---|---|---|
| id | Uygulama içindeki credential kaydını tanımlar. | Veritabanı anahtarı olabilir. |
| user_id | Credential'ı kalıcı kullanıcı hesabıyla eşleştirir. | E-posta veya telefon yerine değişmeyen dahili kullanıcı ID'si kullanın. |
| credential_id | Authenticator tarafından üretilen public-key credential'ı tanımlar. | Binary değeri güvenli biçimde saklayın ve benzersiz indeks uygulayın. |
| public_key | Authentication assertion imzasını doğrulamak için kullanılır. | Özel anahtar sunucuda tutulmaz. |
| sign_count | Desteklenen authenticator'larda anormal kopyalama sinyali sağlayabilir. | Tek başına her durumda kesin ret kuralı yapmayın. |
| transports | Credential'a ulaşılabilecek taşıma yöntemlerini bildirir. | Sonraki kullanıcı deneyimini iyileştirebilir. |
| backup_state / backup_eligible | Credential'ın yedekleme ve senkronizasyon özellikleri hakkında sinyal sağlar. | Kullanıcıya cihaz bağlılığı konusunda açıklama sunmakta kullanılabilir. |
| name | Kullanıcının credential'ı yönetim ekranında tanımasını sağlar. | “İş bilgisayarı” gibi kullanıcı tarafından değiştirilebilir ad desteklenebilir. |
| created_at / last_used_at | Yönetim ve güvenlik görünürlüğü sağlar. | Şüpheli veya artık kullanılmayan kayıtları ayırt etmeye yardımcı olur. |
Kullanıcının mevcut credential ID'leri kayıt seçeneklerindeki excludeCredentials alanına eklenebilir. Bu, aynı passkey sağlayıcısında aynı hesap için gereksiz yinelenen credential oluşturulmasını önlemeye yardımcı olur. Google'ın kayıt rehberi; user.id değerinin kalıcı, rastgele ve kişisel bilgi içermeyen bir tanımlayıcı olması gerektiğini vurgular Google Passkey Registration Guide.
Passkey kayıt akışı web sitesine nasıl eklenir?
İlk sürümde passkey oluşturma işlemini, kullanıcının mevcut yöntemle güvenli biçimde giriş yaptığı hesap ayarları alanında sunmak en kontrollü yaklaşımlardan biridir. Böylece yeni credential'ın hangi hesaba bağlanacağı konusunda belirsizlik azalır. Passkey oluşturma istemi kayıt tamamlandıktan, başarılı şifre ve ikinci faktör girişinden veya hesap kurtarma sonrasında gösterilebilir.
- Kullanıcı güçlü biçimde doğrulanır. Mevcut şifre, MFA, sosyal giriş veya kurumsal kimlik sağlayıcısı üzerinden aktif ve güvenilir oturum sağlanır.
- Frontend kayıt seçeneklerini ister. Backend geçerli oturuma göre kullanıcıyı belirler; istemciden gelen user ID'ye güvenmez.
- Backend challenge ve creation options üretir. RP ID, kullanıcı bilgisi, algoritmalar, authenticator tercihleri ve mevcut credential listesi hazırlanır.
- Challenge geçici olarak saklanır. İşlem türü, kullanıcı, oturum ve kısa geçerlilik süresiyle ilişkilendirilir.
- Frontend WebAuthn create çağrısını başlatır. Tarayıcı uygun passkey sağlayıcısını veya authenticator'ı kullanıcıya sunar.
- Credential sonucu backend'e gönderilir. Binary alanlar HTTPS üzerinden taşınabilecek biçimde kodlanır.
- Sunucu kayıt yanıtını doğrular. Challenge, origin, RP ID hash'i, işlem türü ve gerekli doğrulama bayrakları kontrol edilir.
- Açık anahtar kaydedilir. Credential, aktif kullanıcı hesabıyla ilişkilendirilir ve challenge tüketilir.
- Kullanıcıya anlaşılır onay gösterilir. Passkey'in adı, oluşturulma zamanı ve yönetim ekranına bağlantı sunulur.
Kayıt ekranında yalnızca “Başarılı” mesajı göstermek yeterli değildir. Kullanıcı yeni passkey'in hangi hesap için oluşturulduğunu, sonraki girişte nasıl kullanılacağını ve nereden silinebileceğini görmelidir. FIDO Alliance'ın tasarım kaynakları, passkey oluşturma ve giriş deneyiminin ürün, tasarım ve mühendislik ekipleri tarafından birlikte ele alınmasını önerir FIDO Passkey Design Guidelines.
Passkey ile giriş akışı nasıl tasarlanmalıdır?
Passkey kaydı tamamlandıktan sonra iki temel giriş modeli kullanılabilir. Birincisi, ayrı bir “Passkey ile giriş yap” düğmesidir. İkincisi, mevcut kullanıcı adı alanında conditional UI ve form autofill üzerinden passkey önerileri göstermektir. Geçiş döneminde ikinci yaklaşım, şifre ve passkey kullanıcılarını tek giriş ekranında tutabildiği için daha az yöntem seçme yükü oluşturabilir.
web.dev, form autofill yaklaşımının mevcut şifre kullanıcılarını desteklerken passkey'leri aynı arayüzde sunabildiğini belirtir web.dev Passkey Form Autofill. Kullanıcı adı alanına uygun autocomplete değeri eklenir, conditional mediation destekleniyorsa tarayıcı kayıtlı passkey seçeneklerini otomatik doldurma menüsünde gösterebilir. Passkey bulunamaz veya kullanıcı şifreyi seçerse mevcut akış devam eder.
- Giriş sayfası backend'den tek kullanımlık authentication challenge ister.
- Backend request options üretir ve challenge'ı işlem kaydıyla ilişkilendirir.
- Frontend navigator.credentials.get() akışını düğme veya conditional UI ile başlatır.
- Kullanıcı passkey sağlayıcısını seçer ve cihaz kilidiyle işlemi onaylar.
- Assertion backend'e gönderilir.
- Backend credential ID ile kayıtlı açık anahtarı bulur.
- Challenge, origin, RP ID hash'i, user presence, user verification politikası ve imza doğrulanır.
- Başarılı doğrulama sonrasında güvenli uygulama oturumu oluşturulur.
- Credential'ın son kullanım zamanı ve gerekli audit olayı güncellenir.
İmza doğrulamasının başarılı olması yetkilendirme anlamına gelmez. Kullanıcı doğrulandıktan sonra rol, hesap durumu, tenant erişimi ve hassas işlem izinleri mevcut uygulama kurallarıyla ayrıca denetlenmelidir. Kimlik doğrulama ile yetkilendirme sınırını korumak, geniş kapsamlı yazılım geliştirme projelerinde özellikle önemlidir.
Passkey yönetim ekranında neler bulunmalıdır?
Kullanıcı yeni passkey ekleyebilmeli, kayıtlı passkey'leri ayırt edebilmeli ve artık kullanmadığı credential'ı kaldırabilmelidir. web.dev, kullanıcı başına birden fazla passkey desteğini ve merkezi bir yönetim sayfasını önerir web.dev Passkey Management. Bu ekran yalnız güvenlik ayarı değil, hesap dışında kalmayı önleyen operasyonel bir bileşendir.
- Her passkey için anlaşılır ve düzenlenebilir ad gösterin.
- Oluşturulma ve son kullanılma zamanını gösterin.
- Mümkün olduğunda passkey sağlayıcısı veya cihaz türü hakkında açıklayıcı bilgi verin.
- Kullanıcının ikinci bir passkey eklemesine izin verin.
- Silme işleminden önce yeniden doğrulama isteyin.
- Son giriş yöntemini silmeye çalışan kullanıcıyı hesap dışında kalma riski hakkında uyarın.
- Credential silindiğinde sunucu kaydını kaldırın ve desteklenen ortamlarda passkey sağlayıcısıyla durum uyumunu yönetin.
- Yeni passkey ekleme, silme ve kurtarma işlemlerini audit kaydına alın.
- Şüpheli ekleme veya silme işlemlerinde kullanıcıya güvenlik bildirimi gönderin.
Hesap kurtarma ve fallback nasıl kurulmalıdır?
Passkey entegrasyonunun en kritik bölümlerinden biri, kullanıcı bütün credential'larına erişimini kaybettiğinde ne olacağıdır. Şifreyi fallback olarak açık bırakmak geçişi kolaylaştırabilir; fakat saldırgan hâlâ şifre ve zayıf kurtarma kanalı üzerinden hesaba girebiliyorsa passkey'in sağladığı phishing direnci hesabın tamamına yansımaz.
Kurtarma yöntemi kullanıcı kitlesine ve hesabın riskine göre tasarlanmalıdır. Doğrulanmış e-posta, telefon, yedek authenticator, kurumsal yardım masası, kimlik doğrulama adımları veya daha yüksek riskli hesaplarda manuel inceleme birlikte kullanılabilir. FIDO Alliance, geçişin planlama, pilot, dağıtım ve eğitim aşamalarıyla ele alınmasını; kurtarma ve yedek doğrulama yöntemlerinin açık biçimde belgelenmesini önerir FIDO Passkey Migration Guidance.
| Fallback yaklaşımı | Avantaj | Temel risk | Uygun kullanım |
|---|---|---|---|
| Şifreyi geçici olarak korumak | Mevcut kullanıcılar için geçiş sürtünmesini azaltır. | Şifre hesabın zayıf giriş yolu olmaya devam eder. | Kademeli geçişin erken aşaması |
| Doğrulanmış e-posta veya telefon | Kullanıcıların aşina olduğu kurtarma yöntemidir. | E-posta veya SIM hesabı ele geçirilirse kurtarma kötüye kullanılabilir. | Düşük ve orta riskli tüketici hesapları |
| İkinci passkey veya donanım anahtarı | Phishing dirençli yedek sağlar. | Kullanıcının önceden ikinci credential kaydetmesi gerekir. | Yönetici ve kritik hesaplar |
| Kurumsal yardım masası | Çalışan kimliği ve cihaz politikasıyla bağ kurulabilir. | Sosyal mühendislik ve süreç tutarsızlığı riski taşır. | Kurumsal çalışan hesapları |
| Manuel kimlik incelemesi | Yüksek değerli hesaplarda ek güvence sağlayabilir. | Maliyetli, yavaş ve gizlilik açısından hassastır. | Yüksek riskli özel senaryolar |
Kurtarma başarılı olduğunda kullanıcıya yeni passkey oluşturma fırsatı verilmelidir. Ancak kurtarma oturumunun yetkisi sınırsız olmamalı; ödeme bilgisi değiştirme, tüm passkey'leri silme veya hesap sahibini değiştirme gibi hassas işlemler için bekleme süresi, ek doğrulama veya risk kontrolü uygulanabilir.
Şifreli sistemden passkey'e kademeli geçiş planı
En güvenli geçiş, ölçülebilir aşamalara ayrılmış geçiştir. Her aşamada kayıt başarı oranı, giriş başarı oranı, iptal edilen WebAuthn istemleri, fallback kullanımı, kurtarma talepleri ve destek kayıtları izlenmelidir. Teknik olarak çalışan akışın kullanıcılar tarafından anlaşılmaması, yaygın benimsemeyi engelleyebilir.
- Hazırlık: Domain ve RP ID yapısını, kullanıcı veri modelini, oturum güvenliğini ve kurtarma politikasını denetleyin.
- İç pilot: Geliştirme ekibi ve sınırlı çalışan grubuyla farklı tarayıcı, işletim sistemi ve authenticator senaryolarını test edin.
- İsteğe bağlı kayıt: Güvenlik ayarlarında passkey eklemeyi açın; mevcut şifre akışını koruyun.
- Giriş sonrası teşvik: Başarılı ve güçlü şifre/MFA girişinden sonra kullanıcıya passkey oluşturmayı önerin.
- Birleşik giriş ekranı: Conditional UI veya aynı ekranda passkey ve şifre seçeneklerini sunun.
- Riskli hesaplarda güçlendirme: Yönetici veya kritik kullanıcılar için ikinci passkey ve daha güçlü kurtarma politikası uygulayın.
- Şifre bağımlılığını azaltma: Yeterli kayıt ve başarı oranına ulaşıldığında uygun kullanıcı segmentlerinde şifreyi ikincil yönteme dönüştürün veya kontrollü biçimde kaldırın.
- Sürekli bakım: Tarayıcı değişikliklerini, WebAuthn güncellemelerini, kütüphane sürümlerini ve başarısız giriş sinyallerini izleyin.
Canlıya çıkmadan önce passkey kontrol listesi
- Canlı ortam HTTPS kullanıyor ve izin verilen origin listesi açıkça tanımlı mı?
- RP ID, mevcut ve planlanan alt domainlerle uyumlu mu?
- Challenge kriptografik olarak güvenli, tek kullanımlık ve süreli mi?
- Kayıt ve authentication challenge'ları farklı işlem türleriyle ilişkilendiriliyor mu?
- Sunucu aktif oturumdaki kullanıcıyı esas alıyor mu?
- Origin, RP ID hash'i, challenge, imza ve user verification politikası backend'de doğrulanıyor mu?
- Kullanıcı başına birden fazla credential destekleniyor mu?
- Credential ID benzersizliği veritabanında korunuyor mu?
- Passkey ekleme ve silme işlemleri yeniden doğrulama gerektiriyor mu?
- Son passkey'in silinmesi hesap dışında kalma riskine göre yönetiliyor mu?
- Şifre ve passkey kullanıcıları için birleşik veya anlaşılır giriş deneyimi var mı?
- Tüm passkey'ler kaybedildiğinde uygulanacak kurtarma süreci test edildi mi?
- Başarılı WebAuthn sonrasında session güvenliği ayrıca uygulanıyor mu?
- Kayıt, giriş, silme ve kurtarma olayları güvenli biçimde izleniyor mu?
- Kullanılan FIDO sunucu kütüphanesi güncel ve aktif olarak bakımı yapılan bir sürüm mü?
Sonuç: Passkey entegrasyonu bir kimlik mimarisi projesidir
Passkey'i web sitesine eklemek için istemci tarafında WebAuthn API, sunucu tarafında ise challenge üretimi ve kriptografik doğrulama gerekir. Fakat üretim kalitesini belirleyen asıl unsurlar; doğru RP ID seçimi, kullanıcı başına çoklu credential veri modeli, yönetim ekranı, güvenli oturum, kurtarma politikası ve şifreli kullanıcıların kademeli geçişidir.
En doğru başlangıç, küçük bir kullanıcı grubunda çalışan kayıt ve giriş akışı kurmak; ardından yönetim, kurtarma ve fallback senaryolarını tamamlayarak kapsamı genişletmektir. Mevcut hesap sistemi karmaşıksa passkey dönüşümü, bağımsız bir frontend özelliği yerine özel web yazılımı mimarisinin parçası olarak planlanmalıdır.
Sıkça Sorulan Sorular
Passkey entegrasyonu için mevcut şifre sistemi tamamen kaldırılmalı mı?
İlk aşamada genellikle hayır. Mevcut kullanıcıların tamamında passkey bulunmayacağı ve bazı cihazlarda farklı giriş yöntemlerine ihtiyaç duyulabileceği için şifre kontrollü bir geçiş döneminde korunabilir. Ancak şifre açık kaldığı sürece hesabın saldırı yüzeyinde kalmaya devam ettiği unutulmamalıdır. Kullanıcı passkey benimsemesi, giriş başarı oranı ve kurtarma talepleri ölçüldükten sonra şifre belirli segmentlerde ikincil yönteme dönüştürülebilir veya uygun risk politikasıyla kaldırılabilir.
Passkey entegrasyonunda hazır bir WebAuthn kütüphanesi kullanılmalı mı?
Çoğu projede güncel ve aktif olarak bakımı sürdürülen bir FIDO/WebAuthn sunucu kütüphanesi kullanmak daha güvenli ve sürdürülebilir bir yaklaşımdır. Kütüphane; creation options üretimi, binary veri dönüşümleri, registration ve authentication yanıtlarının doğrulanması gibi karmaşık işlemleri kolaylaştırır. Buna rağmen RP ID, izin verilen origin'ler, challenge yaşam döngüsü, kullanıcı eşleştirme, session güvenliği ve hesap kurtarma politikası uygulama ekibi tarafından doğru yapılandırılmalıdır.
Bir kullanıcı hesabına kaç passkey eklenmelidir?
Veri modeli kullanıcı başına birden fazla passkey desteklemelidir. Kullanıcı telefonundaki senkronize passkey'e ek olarak farklı bir sağlayıcı, başka bir cihaz veya fiziksel güvenlik anahtarı ekleyebilir. İkinci credential hesap dışında kalma riskini azaltabilir. Ancak aynı sağlayıcıda gereksiz yinelenen kayıtları önlemek için mevcut credential ID'leri kayıt seçeneklerinde excludeCredentials alanıyla gönderilebilir. Yönetim ekranı her passkey'i adı ve kullanım bilgileriyle ayırt edebilmelidir.
Passkey kaybolursa kullanıcı hesabını nasıl geri alır?
Kurtarma yöntemi hesabın riskine göre tasarlanmalıdır. Senkronize passkey başka cihazdan kullanılabilir; ayrıca ikinci passkey, doğrulanmış e-posta veya telefon, kurumsal yardım masası ya da daha yüksek riskli hesaplarda manuel inceleme kullanılabilir. Kurtarma kanalı şifre girişinden daha zayıf olmamalıdır. Kurtarma tamamlandıktan sonra yeni passkey oluşturma fırsatı verilmeli ve hassas hesap değişiklikleri için ek doğrulama veya bekleme süresi değerlendirilebilir.
Passkey ve şifre aynı giriş ekranında gösterilebilir mi?
Evet. WebAuthn conditional UI ve form autofill yaklaşımı, kayıtlı passkey'leri mevcut kullanıcı adı alanının otomatik doldurma seçenekleri arasında gösterebilir. Kullanıcı passkey seçerse cihaz kilidiyle giriş yapar; passkey bulunmuyorsa veya kullanıcı şifreyi tercih ediyorsa mevcut form akışı devam eder. Bu yöntem, geçiş döneminde kullanıcıdan önce hangi giriş yöntemini kullandığını hatırlamasını istemeden iki yöntemi aynı arayüzde destekleyebilir.
Passkey entegrasyonu sadece frontend geliştirmesi midir?
Hayır. Frontend yalnızca sunucudan seçenekleri alır, WebAuthn API çağrısını başlatır ve credential yanıtını backend'e iletir. Challenge üretimi, süresi, kullanıcı oturumuyla ilişkilendirilmesi, origin ve RP ID doğrulaması, açık anahtarın saklanması, imza kontrolü, güvenli session oluşturma ve hesap kurtarma backend sorumluluğundadır. Ayrıca kullanıcı başına çoklu credential veri modeli, yönetim ekranı, audit kayıtları ve destek süreçleri gerekir.
