Passkey (Geçiş Anahtarı): E-Ticarette Parolasız Giriş

Müşteriniz daha önce alışveriş yaptığı mağazaya geri geliyor. Sepeti hazır, fakat parolasını hatırlamıyor. Sıfırlama e-postasını bekliyor, başka bir sekmeye geçiyor ve alışveriş yarım kalıyor. Passkey, yani geçiş anahtarı, bu giriş adımında parola yazmak yerine cihazın kilit açma yöntemini kullanabilen bir seçenek sunuyor. web.dev giriş rehberi, mevcut parola formuyla birlikte kullanımını açıklıyor.

E-ticaret ekibi açısından hedef, giriş ekranına yeni bir düğme eklemekten daha geniş: müşterinin hesabına güvenle ulaşmasını, cihazını değiştirdiğinde geri dönebilmesini ve alışverişi tamamlayabilmesini sağlamak. Bu nedenle geçiş planı giriş, hesap yönetimi ve müşteri desteğini birlikte kapsamalı.

Dizüstü bilgisayarındaki mağaza hesabına telefonuyla giriş yapan müşteri

Passkey Hangi Sorunu Çözer?

Web tarafındaki temel standart WebAuthn. Sunucunuz bir açık anahtar saklar; girişte, buna karşılık gelen özel anahtarla üretilmiş imzayı doğrular. Kimlik bilgisi hizmetin alan adı kapsamına bağlıdır. Bu bağ, benzer görünen başka bir alan adının aynı kimlik bilgisini kullanmasını engelleyerek oltalama saldırılarına karşı koruma sağlar. Teknik model W3C WebAuthn belgesinde tanımlanır.

Bunun iş karşılığı, yeniden kullanılabilir bir parolanın giriş sırasında yazılmamasıdır. Ancak ele geçirilmiş bir oturum, zararlı yazılım veya müşteri desteğini kandırarak yapılan hesap kurtarma ayrı risklerdir. Bu rehberdeki önerimiz, passkey projesini yalnızca giriş formunun güvenliğiyle sınırlamamaktır. Teslimat adresi değişikliği, kayıtlı ödeme araçları ve yeni giriş yöntemi ekleme gibi hassas işlemleri ayrıca değerlendirin.

Cihaz Değişince Ne Olacak?

İki türü ayırmak gerekir. Senkronize passkey, sağlayıcının desteklediği cihazlarda aynı sağlayıcı hesabı üzerinden kullanılabilir. Cihaza bağlı passkey ise oluşturulduğu cihazdan ayrılmaz; donanım güvenlik anahtarı bunun bir örneğidir. Her sağlayıcı ve cihaz birleşiminin aynı deneyimi sunduğunu varsaymayın. Biyometri kullanıldığında yüz veya parmak izi verisi mağazanıza gönderilmez; yerel doğrulama cihazda yapılır. Bu ayrımlar FIDO Alliance açıklamasında yer alıyor.

Pilot sırasında şu senaryoları gerçek cihazlarla deneyin: aynı ekosistemde yeni telefon, farklı ekosisteme geçiş, ortak bilgisayar ve kaybolan güvenlik anahtarı. Her senaryoda müşterinin hangi adımı göreceğini destek ekibine de gösterin. “Telefonunu kaybedersen her şey otomatik gelir” gibi kapsamı belirsiz vaatlerden kaçının.

Kurtarmayı İlk Günden Tasarlayın

Kullanıcının birden fazla passkey ekleyebilmesi, bunları tanıyabilmesi ve kaldırabilmesi gerekir. Sağlayıcı adı, oluşturulma tarihi ve son kullanım bilgisi, hesap ekranındaki kayıtları anlaşılır kılar. web.dev yönetim rehberi birden fazla sağlayıcıyı desteklemeyi ve silme işlemini öneriyor.

Mağaza için önerdiğimiz kurtarma akışı üç parçadan oluşuyor:

Erişim sürerken hazırlık: Müşteriye hesap ayarlarından ikinci bir giriş yolu ekletin. Hangi koşullarda işe yarayacağını açıklayın.
Erişim kaybolduğunda doğrulama: Destek ekibinin sipariş numarası bilen herkese hesabı devretmesini önleyen yazılı bir süreç oluşturun. Kullanılacak kanalları, kanıtları ve inceleme sorumlusunu belirleyin.
Kurtarma sonrasında kontrol: Eski giriş yöntemlerini ve açık oturumları gözden geçirin; müşteriyle yeni erişim yöntemini doğrulayın. Yeni passkey kaydını bildirmek de web.dev kayıt akışının önerileri arasında.

Kurtarmada gecikme, başarısızlık ve kötüye kullanım kayıtlarını ayrı tutun. Destek ekibinin çözüm süresini kısaltmak uğruna doğrulamayı atlaması, girişte kazanılan korumayı zayıflatabilir.

Parola ve MFA Hemen Kalkmalı mı?

İlk aşamada mevcut parola akışını korumak makuldür. Uyumlu tarayıcılarda koşullu arayüz, passkey önerisini giriş alanının otomatik doldurma menüsüne taşıyabilir. Kullanıcı hangi yönteme sahip olduğunu baştan seçmek zorunda kalmaz. Bu yaklaşım web.dev otomatik doldurma rehberinde gösteriliyor.

MFA kararını ise yalnızca ekranda kaç adım göründüğüne bağlamayın. WebAuthn, kullanıcının doğrulanıp doğrulanmadığını bildirebilir; uygulamanın talep ettiği doğrulama koşulunu sunucu da kontrol etmelidir. Bu kontrol W3C doğrulama adımlarının parçasıdır. İkinci faktörü kaldırma kararını hesap riskine ve gerçekten uygulanan doğrulamaya göre verin; parola ile devam eden girişlerin korumasını ayrıca sürdürün.

Küçük Bir Pilotla Başlayın

İlk uygulama için dört adımlı bir sıra öneriyoruz:

Mevcut durumu ölçün. Giriş başarısı, parola sıfırlama talebi, girişten alışverişe geçiş ve destek başvurularını kaydedin.
Hesap ekranında sunun. Başarıyla giriş yapan küçük bir müşteri grubuna passkey oluşturma seçeneği gösterin. Kullanıcı reddettiğinde alışverişine devam edebilsin.
Girişi ve kurtarmayı birlikte doğrulayın. Desteklenen tarayıcıları, iptal edilen işlemleri, kaybolan cihazı ve yanlış hesaba anahtar bağlanmamasını kontrol edin. Sunucu doğrulaması için sınanmış bir kütüphane veya kimlik hizmeti kullanımı web.dev tarafından da öneriliyor.
Sonuca göre genişletin. Destek yükü veya giriş başarısızlığı artarsa yeni kayıt davetlerini durdurun; daha önce eklenen passkey’lerin çalışmasını sürdürün.

Bu yaklaşım, KOBİ’ler için dijital dönüşüm rehberindeki küçük pilot mantığını müşteri hesaplarına uygular. Hazır e-ticaret altyapısında önce platformun ve kimlik sağlayıcısının desteklediği akışları inceleyin; tema değişikliği tek başına yeterli olmayabilir.

Başarıyı Nasıl Ölçeceğiz?

Yalnızca oluşturulan passkey sayısını raporlamayın. Oluşturma davetini görenlerin kaçının kayıt yaptığı, sonraki girişte kaçının passkey kullandığı, giriş süresi, kurtarma talebi ve hesap ele geçirme olayları birlikte izlenmeli. Teknik hata, zaman aşımı ve kullanıcının işlemi iptal etmesini tek bir “başarısızlık” başlığında toplamak teşhisi zorlaştırır.

Dönüşüm oranını karşılaştırırken cihaz, trafik kaynağı ve yeni/geri dönen müşteri dağılımını hesaba katın. Passkey’i gönüllü açan müşteriler zaten daha bağlı olabilir. Mümkünse benzer, rastgele ayrılmış gruplarda teklifin etkisini ölçün; yalnızca iki kullanıcı grubunun satış farkından nedensel sonuç çıkarmayın.

Giriş akışınızı, kurtarma sürecinizi ve entegrasyon ihtiyaçlarınızı birlikte değerlendirmek için e-ticaret geliştirme ve güvenlik denetimi hizmetlerimize göz atabilirsiniz.

Kaynaklar ve Güncellik

Bu rehberin kaynakları 5 Eylül 2026 tarihinde kontrol edildi. Pilot planı ve ölçüm önerileri Barlas Dijital’in uygulama değerlendirmesidir; belirli bir satış artışı taahhüdü içermez.