Parolalar uzun zamandır web uygulamalarının vazgeçilmez bir parçası. Kullanıcı kayıt olur, bir kullanıcı adı veya e-posta adresi belirler, parola oluşturur ve sonraki girişlerinde bu parolayı kullanır.

Ancak yıllar içerisinde bu modelin ciddi problemleri ortaya çıktı.

Kullanıcılar aynı parolayı farklı sistemlerde kullanabiliyor. Zayıf parolalar seçebiliyor. Parolalarını unutabiliyor. Phishing saldırılarıyla parolalarını saldırganlara verebiliyor veya parolaları bir veri ihlali sonucunda ele geçirilebiliyor.

Bu nedenle son yıllarda parola yerine farklı kimlik doğrulama yöntemleri giderek daha fazla kullanılmaya başlandı.

Bunlardan biri de Passkey.

.NET 10 ile birlikte ASP.NET Core Identity tarafında WebAuthn tabanlı passkey desteğinin doğrudan framework içerisine gelmesi, özellikle ASP.NET Core uygulamalarında passwordless authentication uygulamak isteyen geliştiriciler açısından önemli bir değişiklik. Microsoft’un dokümantasyonuna göre .NET 10, ASP.NET Core Identity içerisinde WebAuthn/passkey desteği sunuyor.

Bu yazıda passkey’in ne olduğunu, klasik parola sisteminden nasıl farklı çalıştığını ve .NET 10 ile bir ASP.NET Core uygulamasında nasıl kullanılabileceğini adım adım inceleyeceğiz.

Passkey Nedir?

Passkey’i en basit haliyle şöyle tanımlayabiliriz:

Passkey, kullanıcının parolasını hatırlamasına gerek kalmadan, cihazındaki veya parola yöneticisindeki kriptografik kimlik bilgilerini kullanarak oturum açmasını sağlayan WebAuthn tabanlı kimlik doğrulama yöntemidir.

Buradaki önemli nokta şu:

Passkey bir parola değildir.

Sunucuda:

kullanıcı + parola

saklamak yerine, bir public/private key çifti kullanılır.

Kullanıcının cihazında:

Private Key

bulunur.

Sunucuda ise:

Public Key

saklanır.

Private key sunucuya gönderilmez.

Bu ayrım passkey sisteminin temelini oluşturur.

Microsoft’un WebAuthn açıklamasına göre kayıt sırasında cihaz yeni bir kriptografik anahtar çifti oluşturur ve bu anahtar çifti ilgili web servisiyle ilişkilendirilir. Daha sonraki girişlerde cihaz, sunucunun gönderdiği challenge değerini private key ile imzalar; sunucu ise public key kullanarak bu imzayı doğrular.

Parola ile Passkey Arasındaki Fark

Klasik authentication sisteminde akış kabaca şöyledir:

Kullanıcı
   │
   │ Email + Password
   ▼
ASP.NET Core
   │
   ▼
Password Hash
   │
   ▼
Kullanıcı doğrulandı

Örneğin:

POST /login

email=yavuz@example.com
password=123456

Sunucu parolanın hash değerini kontrol eder.

Passkey’de ise durum tamamen farklıdır.

Kullanıcı
   │
   │ "Passkey ile giriş yap"
   ▼
Browser
   │
   ▼
Authenticator
   │
   │ Private Key ile imzala
   ▼
Signed Assertion
   │
   ▼
ASP.NET Core
   │
   │ Public Key ile doğrula
   ▼
Kullanıcı doğrulandı

Burada kullanıcı aslında sunucuya bir parola göndermez.

WebAuthn Nedir?

Passkey’i anlamak için WebAuthn kavramını anlamak gerekiyor.

WebAuthn, Web Authentication API’nin kısaltmasıdır.

Web uygulaması ile kullanıcının cihazındaki authenticator arasında standart bir iletişim mekanizması sağlar.

Örneğin authenticator şu olabilir:

Windows Hello
Face ID
Touch ID
Android biyometrik doğrulama
iPhone/iPad biyometrik doğrulama
FIDO2 güvenlik anahtarı
Destekleyen parola yöneticileri

Microsoft da WebAuthn’ın Windows tarafında Windows Hello ve FIDO2 security key gibi yöntemlerle passwordless authentication uygulamak için kullanılabileceğini belirtiyor.

Dolayısıyla aslında şu üç kavramı birbirinden ayırmak gerekiyor:

Passkey
   ↓
Kullanıcı deneyimi / credential

WebAuthn
   ↓
Web standardı / API

FIDO2
   ↓
Kimlik doğrulama ekosistemi / standartlar

Private Key Neden Sunucuya Gönderilmiyor?

Bu, passkey’in en önemli güvenlik özelliklerinden biridir.

Bir kullanıcı kayıt olduğunda cihazında örneğin:

Private Key
Public Key

oluşturulur.

Sunucuya:

Public Key

gider.

Private Key cihazda kalır.

Daha sonra kullanıcı giriş yaptığında sunucu bir challenge oluşturur:

8a91f0c2...

Authenticator bu challenge’ı private key ile imzalar:

Signature = Sign(Challenge, PrivateKey)

Sunucu ise:

Verify(
    Challenge,
    Signature,
    PublicKey
)

işlemini gerçekleştirir.

Doğrulama başarılıysa kullanıcı authenticated olur.

Passkey Kayıt İşlemi

Bir kullanıcının ilk defa passkey oluşturduğunu düşünelim.

Örneğin kullanıcı hesabını oluşturdu:

yavuz@example.com

ve:

“Passkey oluştur”

butonuna bastı.

Sunucu bir challenge üretir.

Server
   │
   │ Challenge
   ▼
Browser
   │
   ▼
Authenticator

Authenticator kullanıcıdan doğrulama ister:

Windows Hello
Face ID
Touch ID
PIN
Security Key

Kullanıcı doğrulandıktan sonra cihaz bir key pair üretir:

Private Key
Public Key

Sunucu public key’i kaydeder.

Sonuç:

Database

User
 ├── Id
 ├── Email
 └── Passkey
      ├── CredentialId
      ├── PublicKey
      └── Metadata

Microsoft’un ASP.NET Core dokümantasyonunda da passkey kayıt işlemi attestation olarak açıklanıyor; sunucu challenge üretir, authenticator credential oluşturur ve public key’i içeren veriyi sunucuya döndürür.

Giriş İşlemi Nasıl Gerçekleşiyor?

Kullanıcı daha sonra tekrar geldi.

Email

[ Passkey ile giriş yap ]

diyelim.

Sunucu tekrar bir challenge oluşturur.

Challenge = RandomBytes(...)

Browser bunu authenticator’a gönderir.

Authenticator:

PrivateKey
     +
Challenge
     ↓
Signature

üretir.

Sunucuya:

CredentialId
Signature
ClientData
AuthenticatorData

gibi WebAuthn verileri gelir.

Sunucu kayıtlı public key’i bulur.

CredentialId
       ↓
Database
       ↓
PublicKey

Ardından signature doğrulanır.

Verify(
    PublicKey,
    Challenge,
    Signature
)

Başarılıysa:

Authentication Cookie

oluşturulur.

Artık kullanıcı sisteme giriş yapmıştır.

.NET 10 ile Neler Değişiyor?

Daha önce ASP.NET Core uygulamalarında WebAuthn/passkey uygulamak için genellikle üçüncü taraf WebAuthn/FIDO2 kütüphanelerinden yararlanmak gerekiyordu.

.NET 10 ile ASP.NET Core Identity içerisinde doğrudan passkey desteği bulunuyor.

Microsoft’un güncel dokümantasyonunda desteklenen senaryolar arasında:

Mevcut password hesabına passkey ekleme
Passwordless hesap oluşturma
Passwordless sign-in

açıkça belirtiliyor.

Bu oldukça önemli.

Çünkü artık klasik:

ASP.NET Core Identity
+
Password
+
TOTP

modelinin yanına:

ASP.NET Core Identity
+
Passkey

eklemek mümkün.

Örnek Proje

Örneğimizde şöyle bir uygulama oluşturalım:

PasskeyDemo

.NET 10 kullanalım.

Proje yapımız:

PasskeyDemo
│
├── Data
│
├── Models
│
├── Services
│
├── Components
│
├── Program.cs
│
└── appsettings.json

Identity kullanacağız.

Örneğin:

builder.Services.AddDefaultIdentity<ApplicationUser>()
    .AddEntityFrameworkStores<ApplicationDbContext>();

Burada dikkat edilmesi gereken nokta, passkey desteğinin ASP.NET Core Identity kapsamında olmasıdır. Microsoft da mevcut implementasyonun ASP.NET Core Identity’ye özgü olduğunu belirtiyor.

Passkey Ayarları

Passkey davranışı IdentityPasskeyOptions üzerinden yapılandırılabilir.

Örneğin:

builder.Services.Configure<IdentityPasskeyOptions>(options =>
{
    options.ServerDomain = "example.com";
});

Buradaki:

ServerDomain

özellikle önemlidir.

Çünkü passkey credential’ları belirli bir relying party/domain bağlamına bağlıdır.

Örneğin:

example.com

için oluşturulan credential’ın:

fake-example.com

gibi başka bir domain altında kullanılabilmesi beklenmez.

Microsoft’un güvenlik dokümantasyonunda ServerDomain açıkça yapılandırılmadığında RP ID’nin Host header’dan türetilebildiği ve bu nedenle hosting ortamında Host header doğrulamasının önemli olduğu belirtiliyor.

Production ortamında bu konu kesinlikle göz ardı edilmemeli.

HTTPS Neden Önemli?

Passkey uygulamasında production ortamında HTTPS kullanmanız gerekir.

Örneğin:

https://app.mercansoft.com

kullanılmalıdır.

Şöyle bir sistem düşünmeyin:

http://192.168.1.50

WebAuthn’in güvenlik modeli origin kavramına dayanır.

Browser’ın çalıştığı:

scheme
+
host
+
port

bilgileri authentication sürecinin önemli parçalarıdır.

Bu nedenle reverse proxy, domain ve HTTPS yapılandırması passkey sisteminin ayrılmaz parçalarıdır.

ASP.NET Core Identity ile Kullanıcı Modeli

Standart Identity kullanıcı modeliniz şöyle olabilir:

public class ApplicationUser : IdentityUser
{
    public string? FullName { get; set; }
}

Burada passkey bilgilerini doğrudan:

ApplicationUser

içerisine kendiniz eklemek zorunda değilsiniz.

ASP.NET Core Identity passkey credential’larını kendi mekanizması içerisinde yönetebilir.

Bu da önemli bir avantajdır.

Kullanıcıya Passkey Ekleme

Kullanıcı hesabına giriş yaptıktan sonra:

Hesabım
   │
   └── Güvenlik
         │
         └── Passkey'ler

gibi bir sayfa sunabiliriz.

Örneğin:

Kayıtlı Passkey'ler

Windows PC
iPhone
Android Telefon
Security Key

[ Yeni Passkey Ekle ]

Kullanıcı:

Yeni Passkey Ekle

butonuna bastığında browser WebAuthn API’sini başlatır.

Kullanıcı Windows kullanıyorsa örneğin:

Windows Hello

ekranı karşısına çıkabilir.

JavaScript Tarafı

WebAuthn işleminin browser tarafındaki temel API’si:

navigator.credentials.create()

ve:

navigator.credentials.get()

metotlarıdır.

Credential oluşturmak için:

const credential =
    await navigator.credentials.create({
        publicKey: options
    });

Authentication için:

const credential =
    await navigator.credentials.get({
        publicKey: options
    });

kullanılır.

Burada önemli bir nokta var.

Bu kodları rastgele kendimiz tasarlamamalıyız.

WebAuthn tarafında:

challenge
RP ID
user ID
credential ID
authenticator data
client data
signature
user verification

gibi birçok parametre vardır.

Bunların yanlış yönetilmesi authentication sisteminin güvenliğini doğrudan etkiler.

Bu yüzden .NET 10’un Identity desteğinden yararlanmak, standart WebAuthn akışını kendimiz sıfırdan yazmaktan çok daha mantıklıdır.

Passwordless Registration

Passkey’in güzel taraflarından biri, kullanıcının daha ilk kayıt sırasında parola oluşturmadan hesap oluşturabilmesidir.

Örneğin:

Hesap Oluştur

E-posta:
[yavuz@example.com]

[Passkey ile Hesap Oluştur]

Kullanıcı butona bastığında:

Browser
   ↓
Authenticator
   ↓
Windows Hello / Face ID / Touch ID

devreye girer.

Başarılı olursa kullanıcı hesabı oluşturulur.

Böylece:

PasswordHash

oluşturma ihtiyacı ortadan kalkabilir.

Microsoft’un .NET 10 dokümantasyonu passwordless account creation senaryosunu doğrudan desteklenen senaryolardan biri olarak listeliyor.

Passwordless Login

Kullanıcı daha sonra:

https://example.com/login

adresine gelir.

Şöyle bir ekran görebilir:

Giriş Yap

[E-posta]

[ Passkey ile Giriş Yap ]

Kullanıcı passkey seçtiğinde browser uygun credential’ı bulur.

Örneğin:

Windows Hello

kullanıcıdan PIN veya biyometrik doğrulama isteyebilir.

Ardından signature oluşturulur.

Sunucu signature’ı doğrular.

Başarılıysa:

HttpContext.User

authenticated hale gelir.

Passkey Phishing’e Karşı Neden Güçlü?

Passkey’in önemli avantajlarından biri origin binding’dir.

Örneğin gerçek site:

https://mercansoft.com.tr

olsun.

Saldırgan:

https://mercansoft-login.com.tr

adında sahte bir site oluşturabilir.

Kullanıcı sahte siteye girdiğinde browser’ın origin’i farklıdır.

Passkey credential’ı:

mercansoft.com.tr

ile ilişkilendirildiği için sahte domain üzerinde aynı authentication işlemi gerçekleştirilemez.

Bu nedenle passkey, klasik parola phishing saldırılarının önemli bir sınıfına karşı güçlü bir koruma sağlar. Microsoft da passkey/WebAuthn’ı phishing-resistant authentication yöntemi olarak tanımlıyor.

Peki Kullanıcı Telefonunu Kaybederse?

Burada önemli bir konu ortaya çıkıyor.

Passkey:

"Telefonumda kayıtlı tek bir credential var."

şeklinde düşünülmemeli.

Kullanıcı hesabına birden fazla passkey ekleyebilir.

Örneğin:

Yavuz'un hesabı

Passkey #1
Windows PC

Passkey #2
iPhone

Passkey #3
Android

Passkey #4
Security Key

Bu nedenle uygulamanızda:

Passkey Yönetimi

sayfası bulunması oldukça faydalıdır.

Örneğin:

Passkey                  Son Kullanım

Windows PC               Bugün
iPhone                   Dün
Yubikey                  12 gün önce

[Passkey Ekle]

gibi bir yapı kurulabilir.

Passkey Silme

Kullanıcı artık kullanmadığı cihazını hesabından kaldırabilmelidir.

Örneğin:

Windows Laptop
Son kullanım: 03.09.2026

[Sil]

Bu işlem sunucudaki credential’ın kaldırılmasını sağlar.

Böylece eski cihazın authentication yetkisi de sona erer.

Birden Fazla Passkey Kullanmak

Gerçek hayattaki uygulamalarda bu oldukça önemlidir.

Örneğin bir SaaS uygulamanız olduğunu düşünelim.

Kullanıcı:

Laptop
Telefon
Tablet
Security Key

kullanıyor olabilir.

Database tarafında mantıksal olarak:

User
   │
   ├── Passkey 1
   ├── Passkey 2
   ├── Passkey 3
   └── Passkey 4

ilişkisi bulunmalıdır.

Bu yaklaşım tek credential’a bağımlı kalmanızı engeller.

Passkey ve 2FA Aynı Şey mi?

Burada sık yapılan bir yanlış anlaşılma var.

Passkey’i doğrudan:

"2FA kodu"

olarak düşünmemek gerekir.

Passkey passwordless authentication’ın kendisi olabilir.

Örneğin:

Password
+
Authenticator Code

yerine:

Passkey

kullanılabilir.

ASP.NET Core’un güncel passkey dokümantasyonu da passkey’lerin birincil authentication yöntemi olarak kullanılabildiğini ve mevcut implementasyonda yerleşik 2FA olarak değerlendirilmediğini belirtiyor.

Dolayısıyla:

Password + TOTP

ile:

Passkey

aynı authentication modeli değildir.

Passkey + MFA Birlikte Kullanılabilir mi?

Uygulamanızın güvenlik gereksinimlerine göre daha karmaşık authentication politikaları uygulanabilir.

Örneğin normal kullanıcı:

Passkey

kullanabilir.

Ancak kritik bir yönetici işlemi için:

Passkey
+
ek doğrulama

istenebilir.

Örneğin:

Kullanıcı
   ↓
Passkey
   ↓
Admin Panel
   ↓
Kritik işlem
   ↓
Step-up authentication

özellikle finans, yönetim paneli ve kurumsal uygulamalarda değerlendirilebilir.

Database’de Ne Saklanıyor?

Passkey sisteminin en önemli noktalarından biri şudur:

Private key database’de saklanmaz.

Sunucu tarafında credential’ın doğrulanabilmesi için gerekli public credential bilgileri tutulur.

Mantıksal olarak:

Passkey
-------------------------
CredentialId
PublicKey
DisplayName
CreatedAt
LastUsedAt
Transports

gibi bilgiler bulunabilir.

.NET 10 Identity API’lerinde passkey’e ilişkin transport bilgileri gibi metadata’ların da modellenebildiğini Microsoft API dokümantasyonu gösteriyor.

Challenge Neden Her Seferinde Değişiyor?

Authentication sırasında sunucu her işlem için yeni bir challenge üretir.

Örneğin:

Challenge #1
a82d91...

Challenge #2
4f91aa...

Challenge #3
c71e21...

Bunun amacı replay attack riskini azaltmaktır.

Saldırgan daha önce elde ettiği:

Signature

verisini tekrar gönderdiğinde aynı challenge beklenmediği için doğrulama başarısız olur.

Basitleştirilmiş haliyle:

Server
   │
   │ Random Challenge
   ▼
Authenticator
   │
   │ Signature
   ▼
Server
   │
   ├── Challenge doğru mu?
   ├── Origin doğru mu?
   ├── RP ID doğru mu?
   ├── Credential doğru mu?
   └── Signature doğru mu?

Bütün kontroller başarılı olduğunda authentication tamamlanır.

ASP.NET Core Uygulamasında Mimari

Kurumsal bir .NET 10 uygulaması için ben authentication katmanını uygulamanın geri kalanından mümkün olduğunca ayırmayı tercih ederim.

Örneğin:

MyApp
│
├── Web
│
├── Application
│
├── Domain
│
├── Infrastructure
│
└── Identity

Identity tarafında:

Identity
│
├── ApplicationUser
├── Authentication
├── Passkeys
└── Authorization

gibi bir yapı oluşturulabilir.

Böylece passkey mekanizması business logic’in içine dağılmaz.

MVC Uygulamasında Kullanılabilir mi?

Evet.

Passkey sadece Blazor’a özgü bir teknoloji değildir.

Ancak .NET 10’daki Microsoft’un hazır passkey yönetimi açısından önemli bir ayrıntı var:

Microsoft’un mevcut template desteği özellikle Blazor Web App içerisinde hazır olarak geliyor.

Bu, MVC uygulamalarında passkey kullanılamaz anlamına gelmez.

MVC uygulamasında da:

ASP.NET Core Identity
+
WebAuthn
+
JavaScript WebAuthn API

üzerinden gerekli UI ve authentication akışları uygulanabilir.

Özellikle mevcut bir MVC projesine passkey ekliyorsanız bunu dikkate almak gerekir.

.NET MAUI ile Passkey

Passkey konusu sadece web uygulamalarında da kalmıyor.

.NET MAUI 10 tarafında da passkey API’leri bulunuyor.

MAUI tarafındaki yaklaşım oldukça ilginç:

MAUI
  │
  │ WebAuthn JSON
  ▼
Native Passkey API
  │
  ▼
Device Authenticator

Microsoft’un MAUI dokümantasyonunda Passkeys.CreateAsync ve Passkeys.AssertAsync API’lerinin native WebAuthn ceremony’sini çalıştırdığı ve standart WebAuthn JSON ile backend’e bağlandığı açıklanıyor.

Bu sayede aynı backend mimarisi:

ASP.NET Core API
       │
       ├── Web
       │
       ├── Android
       │
       ├── iOS
       │
       └── MAUI

tarafından kullanılabilir.

Web + Mobile Ortak Authentication

Örneğin bir SaaS uygulamanız olduğunu düşünelim.

Backend:

ASP.NET Core Web API

Web:

ASP.NET Core MVC

Mobile:

.NET MAUI

olabilir.

Authentication merkezi backend’de tutulur.

                ASP.NET Core API
                       │
              ┌────────┴────────┐
              │                 │
            Web               MAUI
              │                 │
          WebAuthn          Native Passkey

Bu mimari özellikle uzun vadeli projelerde oldukça kullanışlıdır.

Passkey Uygularken Yapılabilecek Hatalar

Passkey kullanmaya karar veren geliştiricilerin en sık yaptığı hatalardan biri, WebAuthn protokolünü tamamen kendi başına uygulamaya çalışmaktır.

Örneğin:

GenerateRandomKey();
SavePublicKey();
VerifySignature();

gibi birkaç metod yazarak sistemi tamamladığını düşünmek doğru değildir.

WebAuthn içerisinde:

RP ID
Origin
Challenge
User verification
Authenticator data
Client data
Signature counter
Credential ID
Attestation
Assertion

gibi birçok detay vardır.

Authentication güvenliği açısından bu alanlardan herhangi birinin yanlış uygulanması ciddi sonuçlar doğurabilir.

Bu nedenle mümkün olduğunca ASP.NET Core Identity’nin sağladığı mekanizmaları kullanmak daha doğru bir yaklaşımdır.

Attestation Nedir?

Passkey kayıt sırasında karşımıza çıkan bir diğer kavram:

Attestation

Attestation, authenticator’ın oluşturduğu credential hakkında bilgi sağlayan mekanizmadır.

Kayıt süreci:

Client
  │
  │ Create Credential
  ▼
Authenticator
  │
  │ Attestation
  ▼
Server

şeklinde düşünülebilir.

Ancak önemli bir ayrıntı var.

ASP.NET Core’un mevcut passkey implementasyonunda attestation statement doğrulaması varsayılan olarak yapılmıyor. Microsoft bunu mevcut sınırlamalardan biri olarak açıkça belirtiyor.

Çoğu tüketici uygulaması için bu ayrım önemli olmayabilir.

Ancak:

Bankacılık
Kurumsal güvenlik
Özel donanım politikaları
Yüksek güvenlik gerektiren sistemler

gibi senaryolarda attestation gereksinimleri ayrıca değerlendirilmelidir.

Host Header Güvenliği

Passkey uygulamasında gözden kaçabilecek bir başka konu:

Host Header

ASP.NET Core passkey implementasyonunda ServerDomain açıkça belirtilmediğinde RP ID’nin host bilgisinden türetilebilmesi nedeniyle reverse proxy ve hosting yapılandırması önem kazanır.

Örneğin:

Internet
   ↓
Nginx
   ↓
ASP.NET Core

kullanıyorsanız host bilgisinin güvenilir şekilde aktarılması gerekir.

Production sistemlerde:

Forwarded Headers
HTTPS
Host validation
ServerDomain

konuları birlikte ele alınmalıdır.

Passkey Recovery Problemi

Passwordless sistemlerde en önemli tasarım problemlerinden biri:

Kullanıcı tüm passkey’lerini kaybederse ne olacak?

Örneğin kullanıcı:

Telefonunu kaybetti
Laptop bozuldu
Security Key kayboldu

ve başka credential’ı yok.

Bu durumda recovery mekanizması gerekir.

Ancak burada dikkatli olmak gerekiyor.

Şöyle bir sistem:

"Email adresine kod gönder,
passkey'i bypass et."

diyerek tasarlanırsa passkey’in sağladığı güvenlik seviyesi düşebilir.

Bu nedenle recovery mekanizması uygulamanın risk seviyesine göre tasarlanmalıdır.

Örneğin:

Recovery Code
Backup Passkey
Admin-assisted recovery
Verified device
Identity verification

gibi yöntemler değerlendirilebilir.

Passkey ve E-posta Aynı Şey Değildir

Şöyle bir kullanıcı deneyimi düşünelim:

Email
[yavuz@example.com]

[Devam Et]

Passkey
[Windows Hello]

Burada e-posta:

Account Identifier

olarak kullanılabilir.

Ama authentication:

Passkey

ile yapılır.

Bu ayrımı mimaride net tutmak faydalıdır.

Passwordless Authentication’ın Büyük Avantajı

Klasik sistem:

User
 ↓
Password
 ↓
Hash
 ↓
Verify

Passkey:

User
 ↓
Authenticator
 ↓
Private Key
 ↓
Signature
 ↓
Public Key Verification

şeklindedir.

Sunucunun kullanıcı parolasını saklama ihtiyacı ortadan kalkabilir.

Bu da:

Password database breach
Password reuse
Weak password
Password phishing
Password reset

gibi problemlerin önemli bir bölümünü azaltır.

Ama bu:

“Passkey kullanırsanız uygulamanız otomatik olarak tamamen güvenli olur.”

anlamına gelmez.

XSS, CSRF, session hijacking, authorization hataları, insecure API’ler ve sunucu güvenliği gibi diğer güvenlik problemleri devam eder.

ASP.NET Core’un güvenlik dokümantasyonu da authentication’ın yanında XSS, SQL injection, CSRF ve open redirect gibi diğer web güvenliği alanlarının ayrıca ele alınması gerektiğini vurguluyor.

Passkey Her Uygulamada Kullanılmalı mı?

Bunu doğrudan “evet” şeklinde cevaplamak doğru olmaz.

Uygulamanın kullanıcı kitlesi, platformları ve recovery gereksinimleri değerlendirilmelidir.

Örneğin:

SaaS

Passkey
+
Email fallback

mantıklı olabilir.

Kurumsal uygulama

Passkey
+
Kurumsal Identity Provider

değerlendirilebilir.

Yüksek güvenlik gerektiren sistem

Passkey
+
Security Key
+
Step-up authentication

gibi daha sıkı politikalar uygulanabilir.

Mevcut Password Sistemini Bir Anda Kaldırmak Gerekir mi?

Hayır.

.NET 10’un önemli avantajlarından biri mevcut password tabanlı Identity sistemlerine passkey ekleyebilmenizdir. Microsoft bunu doğrudan desteklenen senaryolardan biri olarak tanımlıyor.

Örneğin geçiş süreci şöyle olabilir:

Aşama 1

Password
+
TOTP

↓

Aşama 2

Password
+
Passkey

↓

Aşama 3

Passkey
+
Recovery

↓

Aşama 4

Passwordless

Bu yaklaşım mevcut kullanıcıların sisteme erişimini bozmadan kademeli geçiş yapılmasını sağlar.

Gerçek Bir SaaS Uygulamasında Nasıl Tasarlardım?

Örneğin MercanSoft yani kendi şirketim 🙂 tarafından geliştirilen bir SaaS uygulaması olduğunu düşünelim.

Authentication mimarisi:

                    ┌───────────────┐
                    │   User        │
                    └───────┬───────┘
                            │
                ┌───────────┴───────────┐
                │                       │
           Web Browser              Mobile App
                │                       │
           WebAuthn                 Native API
                │                       │
                └───────────┬───────────┘
                            │
                     ASP.NET Core API
                            │
                     ASP.NET Identity
                            │
                     ┌──────┴──────┐
                     │             │
                  User         Passkeys

Passkey tablosunda mantıksal olarak:

CredentialId
PublicKey
DisplayName
CreatedAt
LastUsedAt

gibi bilgiler tutulabilir.

Kullanıcı panelinde:

Güvenlik

Passkey'ler

✓ Windows PC
✓ iPhone
✓ Security Key

[ + Passkey Ekle ]

bulunabilir.

sonuç olarak .NET 10 ile ASP.NET Core Identity’nin WebAuthn tabanlı passkey desteği, ASP.NET Core uygulamalarında passwordless authentication geliştirmeyi önceki sürümlere göre çok daha erişilebilir hale getiriyor.

Passkey’in temel çalışma mantığı aslında oldukça net:

Kayıt:

Authenticator
     ↓
Private Key + Public Key
     ↓
Server
     ↓
Public Key


Giriş:

Server
     ↓
Challenge
     ↓
Authenticator
     ↓
Private Key
     ↓
Signature
     ↓
Server
     ↓
Public Key ile doğrulama
     ↓
Authenticated

En önemli nokta ise şu:

Sunucu kullanıcının private key’ini hiçbir zaman almaz.

Bu nedenle klasik:

Email + Password

modelinden:

Account Identifier
+
Passkey

modeline geçmek mümkün hale gelir.

.NET 10’un ASP.NET Core Identity içerisinde sunduğu passkey desteği; mevcut password tabanlı hesaplara passkey ekleme, tamamen passwordless hesap oluşturma ve passwordless login gibi senaryoları destekliyor.

Bununla birlikte passkey’i sadece bir “login butonu” olarak görmek yanlış olur. Origin, RP ID, HTTPS, Host Header, recovery, credential yönetimi ve authorization gibi konuların tamamı sistemin güvenliğinin bir parçasıdır.

Özellikle yeni bir .NET 10 projesi geliştiriyorsanız passkey’i sonradan eklenecek bir özellik olarak değil, authentication mimarisinin başından itibaren düşünmek çok daha sağlıklı olacaktır.

Kısacası: Parola kullanıcının bir sırrı bilmesine dayanırken, passkey kullanıcının cihazındaki kriptografik credential ile sunucunun challenge’ını doğrulamaya dayanır. Bu mimari, modern web uygulamalarında hem kullanıcı deneyimini hem de phishing’e karşı dayanıklılığı önemli ölçüde iyileştirebilir.

Passkey Nedir?

Parola ile Passkey Arasındaki Fark

WebAuthn Nedir?

Private Key Neden Sunucuya Gönderilmiyor?

Passkey Kayıt İşlemi

Giriş İşlemi Nasıl Gerçekleşiyor?

.NET 10 ile Neler Değişiyor?

Örnek Proje

Passkey Ayarları

HTTPS Neden Önemli?

ASP.NET Core Identity ile Kullanıcı Modeli

Kullanıcıya Passkey Ekleme

JavaScript Tarafı

Passwordless Registration

Passwordless Login

Passkey Phishing’e Karşı Neden Güçlü?

Peki Kullanıcı Telefonunu Kaybederse?

Passkey Silme

Birden Fazla Passkey Kullanmak

Passkey ve 2FA Aynı Şey mi?

Passkey + MFA Birlikte Kullanılabilir mi?

Database’de Ne Saklanıyor?

Challenge Neden Her Seferinde Değişiyor?

ASP.NET Core Uygulamasında Mimari

MVC Uygulamasında Kullanılabilir mi?

.NET MAUI ile Passkey

Web + Mobile Ortak Authentication

Passkey Uygularken Yapılabilecek Hatalar

Attestation Nedir?

Host Header Güvenliği

Passkey Recovery Problemi

Passkey ve E-posta Aynı Şey Değildir

Passwordless Authentication’ın Büyük Avantajı

Passkey Her Uygulamada Kullanılmalı mı?

SaaS

Kurumsal uygulama

Yüksek güvenlik gerektiren sistem

Mevcut Password Sistemini Bir Anda Kaldırmak Gerekir mi?

Gerçek Bir SaaS Uygulamasında Nasıl Tasarlardım?

Kaynaklar

Bir yanıt yazın Yanıtı iptal et