WebAuthn Signal API: İstemci Tarafında Passkey'leri Güncelleme ve Silme

Looking for a dev-focused passkey reference? Download our Passkeys Cheat Sheet. Trusted by dev teams at Ally, Stanford CS & more.

Get Cheat Sheet

Son güncelleme: 4 Kasım 2025

Platformlar arası WebAuthn Signal API desteğine hızlı bir bakış:

⚠️ Bilinen Sorun: Safari 26+'da promise yapısının düzgün çözülmemesine neden olan bir hata var (WebKit Bug #298951). Düzeltme birleştirilmeyi bekliyor.

Passkey ekosistemi sürekli gelişiyor. Değişimi kolaylaştırmak adına temel WebAuthn standardı da hızla ilerliyor. Yeni özellikler genellikle GitHub'da teknik bir açıklayıcı (explainer) metinle başlar ve yeterince tartışıldıktan sonra standart taslağına bir "pull request" (çekme isteği) olarak eklenir. Yakın zamanda, bu pull request standart taslağına WebAuthn Signal API olarak eklendi. Bu yazıda şunları ele alacağız:

• WebAuthn Signal API'ye neden ihtiyaç var: WebAuthn Signal API hangi kullanım durumlarını destekliyor?
• WebAuthn Signal API nasıl çalışır: WebAuthn Signal API tam olarak nasıl işler? Relying Party'ler (güvenen taraflar) için öneriler nelerdir?

Bu yazının yazıldığı sırada, WebAuthn Signal API Chrome 132'den itibaren varsayılan olarak etkindir. Daha önce "Reporting API" olarak biliniyordu ancak aynı isme sahip başka bir API ile karışıklığı önlemek için yeniden adlandırıldı.

WebAuthn Signal API, passkey'lerin istemci tarafında yönetilmesiyle ilgili belirli kullanım durumlarını ele alır. Özellikle, Relying Party (RP) ile istemci tarafı işletim sistemlerinin bir parçası olan authenticator'lar (doğrulayıcılar) arasındaki bilgilerin senkronize edilmesine yardımcı olur. Aşağıdaki önemli kullanım durumları mevcuttur:

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Bir passkey oluşturulduğunda birkaç parça bilgi içerir: user.id, user.name ve user.displayName. Passkey'in kendisi benzersiz Credential ID aracılığıyla tanımlanır.

• user.id: Passkey'in bağlı olduğu hesabı temsil eden benzersiz bir tanımlayıcıdır. Bu user.id kritiktir çünkü passkey'in kullanıcı hesabıyla fiili eşleşmesi için kullanılır.
• user.name ve user.displayName: Bunlar yalnızca kullanıcı arayüzünde görüntüleme amacıyla kullanılan meta verilerdir.

Aşağıdaki görsel, hangi bilginin genellikle hangi alanda saklandığını açıklayan tipik, basit bir veritabanı yapısını göstermektedir:

Şunu anlamak önemlidir: user.name (genellikle bir e-posta adresi) ve user.displayName (daha dostane, okunabilir bir isim) kullanıcının seçim arayüzünde hesabını tanımasına yardımcı olsa da, bir passkey ile bir hesap arasındaki gerçek ilişki user.id ve Credential ID üzerinden sürdürülür:

• Bir hesabın birden fazla passkey'i olabilir, ancak her passkey benzersiz bir şekilde tanımlanır ve user.id kullanılarak hesapla eşleştirilir.
• Her passkey'in, authenticator tarafından oluşturulan benzersiz bir Credential ID'si vardır.

user.name (örneğin bir e-posta adresi) değiştiğinde bir sorun ortaya çıkar. Şu anda, bu değişikliği doğrudan istemci tarafı authenticator üzerinde güncellemek için bir mekanizma yoktur. Kullanıcı e-posta adresini güncellediğinde olduğu gibi user.name çeşitli nedenlerle değişebilir. Sunucu tarafında hesabın meta verilerindeki bu değişikliğe rağmen, eski user.name kimlik bilgisi seçim ekranında görünmeye devam eder ve bu da kullanıcılar için kafa karışıklığına neden olabilir.

Bu sorunun geçici çözümü, güncellenmiş user.name ve aynı user.id ile yeni bir passkey oluşturmak ve ardından mevcut passkey'in üzerine yazmaktır. Ancak, bu yaklaşım birkaç nedenden dolayı zahmetlidir:

1. Gereksizlik: Bir authenticator, belirli bir Relying Party ID için her user.id başına yalnızca bir passkey saklayabilir. Bu, meta verileri güncellemek için eski passkey'in yenisiyle değiştirilmesi gerektiği anlamına gelir ki bu da ekstra bir adımdır.
2. Kullanıcı Deneyimi: Kullanıcılar neden yeni bir passkey oluşturmaları gerektiğini anlamayacaktır. Bu geçici çözümün yaygın olarak kullanılmamasının nedeni budur.
3. Karmaşıklık: Sadece meta verileri güncellemek için passkey oluşturma ve değiştirme süreçlerini yönetmek gereksiz bir karmaşıklıktır.

E-posta adresleri, telefon numaraları ve diğer tanımlayıcılar düzenli olarak değişebilir. user.name ve user.displayName bilgilerini doğrudan authenticator üzerinde güncellemenin basit bir yolu olmadan, kullanıcılar eski e-posta adresleriyle ilişkili bir passkey görüp onu seçmek zorunda kaldıkları kalıcı bir sorunla karşılaşabilirler. Bu durum, passkey'lerin sağlamayı amaçladığı sorunsuz deneyimi zedeler. WebAuthn Signal API, relying party'lerin yeni passkey'ler oluşturmaya gerek kalmadan passkey meta verilerindeki güncellemeleri bildirmesine izin vererek bu sorunu çözmeyi amaçlar. Signal API'yi nasıl uygulayacağımızı açıklamadan önce, ele aldığı ikinci önemli kullanım durumunu inceleyelim.

Become part of our Passkeys Community for updates & support.

Join

Bir diğer kritik kullanım durumu, passkey'lerin istemci tarafı authenticator'dan silinmesidir. Zamanla, kullanıcılar passkey yönetim listesi üzerinden kimlik bilgilerini iptal edebilir veya hesaplarını silebilirler. Bu durumda, bu kimlik bilgilerinin gelecekteki seçim arayüzlerinde (Conditional UI / passkey otomatik doldurma) görünmesini önlemek için istemci tarafı authenticator'dan kaldırıldığından emin olunması gerekir.

Bu işlevselliğe duyulan ihtiyaç çeşitli senaryolarda ortaya çıkar:

1. Hesap ayarları üzerinden silinen passkey: Bir kimlik bilgisi artık geçerli olmadığında, örneğin bir kullanıcı hesap ayarları üzerinden bunu açıkça sildikten sonra:

Kullanıcı perspektifinden bakıldığında, yukarıdaki gibi bir diyalog penceresinde, hesap ayarlarından yapılan bir silme işleminin passkey'in bu cihazdan/istemciden kaldırılmasına yol açmadığını anlamak zordur.

2. Hesap Silme: Bir kullanıcı hesabını sildiğinde, ilişkili tüm passkey'ler de kaldırılmalıdır.

3. Güvenlik Politikaları: Relying party'ler, hareketsizlik sürelerinden sonra veya tespit edilen güvenlik sorunları nedeniyle kimlik bilgilerinin iptal edilmesini gerektiren güvenlik politikalarına sahip olabilir.

Passkey'leri istemci tarafında doğrudan silmek için bir yöntem olmadığında, bu eski veya geçersiz kimlik bilgileri seçim arayüzünü doldurmaya devam ederek kafa karışıklığına yol açar. Kullanıcılar artık geçerli olmayan passkey'leri görüp kullanmaya çalışabilir, bu da başarısız kimlik doğrulama girişimlerine ve kötü bir kullanıcı deneyimine neden olur.

Corbado Connect Yönetim Konsolu'nda sunucu tarafı passkey'lerin nasıl silineceğini görmek için bu videoya göz atın:

WebAuthn Signal API'yi uygulamak, işlevselliğin doğru ve güvenli bir şekilde entegre edildiğinden emin olmak için birkaç adım ve husus içerir. Signal API, Relying Party'lerin (RP'ler) istemci tarafı authenticator üzerindeki passkey kimlik bilgilerini güncellemesine veya silmesine olanak tanır. Bu bölüm, uygulama için temel hususları ve adımları özetlemektedir.

WebAuthn Signal API'yi uygularken aşağıdaki hususları akılda tutmak çok önemlidir:

• Gizliliği Koruma: WebAuthn Signal API, WebAuthn'in temellerinden biri olduğu için kullanıcı gizliliğini korumak üzere tasarlanmıştır. Bu, talep edilen değişikliğin işlenip işlenmediği hakkında RP'ye herhangi bir geri bildirim sağlanmadığı anlamına gelir. API, kimlik bilgilerinin durumu hakkında potansiyel bilgi sızıntısını önlemek için sessizce çalışır.

• Authenticator Erişilebilirliği: WebAuthn Signal API'nin etkinliği, authenticator'ın kullanılabilirliğine bağlıdır. Bu, hem fiziksel kullanılabilirliği hem de yazılım desteğini (örneğin, tarayıcı ve işletim sistemi uyumluluğu) içerir. Tarayıcı, yalnızca authenticator erişilebilir olduğunda ve biyometrik doğrulama gerektirmeden gerekli işlemleri destekliyorsa eylemleri gerçekleştirebilir.

• Alan Adı Kısıtlamaları: API, yalnızca belirli bir alan adıyla ilişkili Relying Party'nin o alan adıyla ilgili kimlik bilgilerinde değişiklik talep edebilmesini sağlar. Bu, üçüncü tarafların yetkisiz değişiklikler yapmasını önlemek için bir güvenlik önlemidir.

• Anahtar Olarak Credential ID: Passkey'lere başvururken, Credential ID (Kimlik Bilgisi Kimliği) WebAuthn Signal API tarafından kullanılan birincil anahtardır. Bu ID, istemci tarafı authenticator üzerindeki passkey'i benzersiz bir şekilde tanımlar. API, RP'lerin passkey'lerle ilişkili meta verileri değiştirmesine veya belirli passkey'lere artık erişilmemesi gerektiğini bildirmesine izin verir, ancak bu yalnızca Credential ID aracılığıyla yapılır. Bir authenticator belirli bir Credential ID'yi bilmiyorsa, sessizce yok sayacaktır.

Bu hususlar, WebAuthn Signal API işlevlerinin en önemli yönlerini anlamak için gereklidir.

WebAuthn Signal API, Relying Party'lerin (RP'ler) istemci tarafı authenticator'lardaki passkey'lerle ilişkili meta verileri güncellemesi için basitleştirilmiş bir mekanizma sağlar. Bu, kullanıcıların gereksiz yere yeni passkey'ler oluşturmak zorunda kalmadan kimlik bilgisi seçim arayüzünde doğru ve güncel bilgileri görmelerini sağlamak için özellikle önemlidir. İşte API'nin bunu nasıl sağladığı:

signalCurrentUserDetails(options) ile Meta Verileri Güncelleme

Signal API'deki signalCurrentUserDetails(options) yöntemi, özellikle passkey'lerin meta verilerini güncellemek için tasarlanmıştır. Bu yöntem, RP'lerin user.name ve user.displayName için güncel değerleri sağlamasına olanak tanır.

Süreç şöyle işler (ayrıca WebAuthn Level 3 standardına bakın):

1. Yöntem Yapısı: signalCurrentUserDetails(options) yöntemi rp.id, user.id ve user.name ile user.displayName için güncel değerleri içerir.

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "aabbcc", // kullanıcı tanıtıcısı (user handle), base64url formatında.
    name: "Yeni kullanıcı adı",
    displayName: "Yeni görünen isim",
});

2. Yerel Meta Verileri Güncelleme: Yerel olarak (authenticator üzerinde) mevcut olan ve rpId ile userId eşleşen kimlik bilgilerini arar. Eşleşen tüm kimlik bilgileri için authenticator, kimlik bilgisinin name ve displayName alanlarını günceller.

3. Gizliliği Koruma: Süreç gizliliği koruyacak şekilde tasarlanmıştır. Signal API, güncellemelerin başarıyla işlenip işlenmediği hakkında RP'ye geri bildirim sağlamaz, böylece kimlik bilgilerinin durumu hakkında herhangi bir bilgi sızıntısı önlenir.

4. Cihazlar Arası Tutarlılık: RP'ler signalCurrentUserDetails(options) yöntemlerini düzenli olarak çalıştırarak, passkey meta verilerinin kullanıcının kimlik doğrulaması yapabileceği farklı cihazlar ve platformlar arasında tutarlı kalmasını sağlayabilir. Bu yaklaşım, kimlik bilgisi seçim arayüzünde eski veya yanlış bilgilerin görüntülenme ihtimalini azaltır.

Yukarıdaki ekran görüntüsünde, Google Chrome'un böyle bir güncellemeyi kullanıcıya nasıl bildirdiğini görebilirsiniz. WebAuthn Signal API, Chrome'un bir parçasıdır ve masaüstünde Google Password Manager ile test edilebilir.

WebAuthn Signal API, Relying Party'lerin (RP'ler) istemci tarafı authenticator'lardan passkey silme işlemini bildirmesi için mekanizmalar sağlar. Bu, eski veya geçersiz kimlik bilgilerinin seçim arayüzünde görünmemesini sağlamak ve böylece sade ve güvenli bir kullanıcı deneyimi sürdürmek için gereklidir. Passkey'leri yerel olarak silmek için iki yöntem vardır: signalUnknownCredential(options) ve signalAllAcceptedCredentials(options). İlki, kullanıcının kimliğinin doğrulanmadığı durumlarda kullanılabilirken, ikincisi kullanıcı kimliği doğrulandığında kullanılabilir. Bu nedenle, gizlilik nedenleriyle ikincisi tercih edilmelidir.

İşte iki yöntemin çalışma şekli:

1. Yöntem Yapısı: signalUnknownCredential(options) yöntemi rpId (relying party ID) ve credentialId (silinecek kimlik bilgisinin benzersiz tanımlayıcısı) içerir.

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc", // kullanıcının az önce denediği credential id, base64url
});

2. Yöntemi Çağırma: RP'ler, bir kimlik bilgisinin silinmesi gerektiğini tespit ettiklerinde bu yöntemi çağırır. Bu, geçersiz bir kimlik bilgisiyle yapılan bir kimlik doğrulama girişiminin hemen ardından, hesap silme sırasında veya bir kullanıcı hesap ayarları aracılığıyla bir kimlik bilgisini iptal ettiğinde olabilir.

3. Yöntemin İşlenmesi: signalUnknownCredential(options) yöntemi çağrıldığında, istemci tarafı authenticator, rpId ve credentialID ile eşleşen kimlik bilgilerini bulmaya çalışır. Authenticator yeteneklerine bağlı olarak, kimlik bilgisi kaldırılır veya gelecekteki kimlik doğrulama seremonilerinde kimlik bilgisini gizlemek için authenticator'a özgü bir prosedür uygulanır.

1. Yöntem Yapısı: signalAllAcceptedCredentials(options) yöntemi rpId (relying party ID), userId ve geçerli Credential ID'lerin bir listesi olan allAcceptedCredentialIds (saklanması gereken kimlik bilgilerinin benzersiz tanımlayıcılarının listesi) içerir.

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "aabbcc", // kullanıcı tanıtıcısı, base64url.
    allAcceptedCredentialIds: ["bb"],
});

2. Yöntemi Çağırma: RP'ler, bir kimlik bilgisinin silinmesi gerektiğini tespit ettiklerinde bu yöntemi çağırır ve geçerli kimlik bilgilerinin bir listesini bildirir. Kimlik bilgilerini silmek için bu yöntem signalUnknownCredential(options) yöntemine tercih edilmelidir.

3. Yöntemin İşlenmesi: signalAllAcceptedCredentials(options) yöntemi çağrıldığında, istemci tarafı authenticator rpId ve userId eşleşmesini sağlar. Authenticator daha sonra rpId ve userId ile eşleşen tüm yerel kimlik bilgilerini arar. Sonuç allAcceptedCredentialIds ile karşılaştırılır. Eğer allAcceptedCredentialIds listesinde olmayan yerel kimlik bilgileri varsa, bu kimlik bilgileri yerel olarak kaldırılır (veya authenticator'a bağlı olarak gizlenir).

4. Kimlik Bilgilerini Görünür Yapma: Eğer kimlik bilgileri sadece gizlenmişse (authenticator'a bağlı olarak) ve şimdi allAcceptedCredentialIds listesinin bir parçasıysa, bu kimlik bilgileri gelecekteki kimlik doğrulama seremonilerinde tekrar mevcut olacaktır.

5. Faydalı İpuçları:

   • signalAllAcceptedCredentials(options) kullanılırken, authenticator'ların bu yöntem çalıştırıldığında her zaman bağlı olmayabileceğini unutmamak önemlidir. Sonuç olarak, Relying Party'ler, tüm kimlik bilgilerinin güncel olduğundan emin olmak için her oturum açma işlemi sırasında signalAllAcceptedCredentials(options) yöntemini periyodik olarak çalıştırmayı düşünebilir.
   • Relying Party'ler, kimlik bilgisi ID'leri listesini (allAcceptedCredentialIds) belirtirken dikkatli olmalıdır. Bu listeye dahil edilmeyen kimlik bilgileri authenticator tarafından gizlenebilir veya kalıcı olarak silinebilir. Geçerli kimlik bilgilerinin yanlışlıkla hariç tutulmasını önlemek için listenin eksiksiz olduğundan emin olmak çok önemlidir. Eğer geçerli bir kimlik bilgisi ID'si yanlışlıkla dışarıda bırakılırsa, authenticator bunu destekliyorsa tekrar görünür hale getirmek için mümkün olan en kısa sürede signalAllAcceptedCredentials(options) içine yeniden eklenmelidir.
   • Mümkün olduğunda, authenticator'lar kimlik bilgilerini kalıcı olarak kaldırmak yerine geçici olarak gizlemeyi tercih etmelidir. Bu yaklaşım, geçerli bir kimlik bilgisi ID'si Relying Party tarafından yanlışlıkla atlanırsa, kalıcı kayıp olmadan geri yüklenmesine izin vererek kurtarmayı kolaylaştırabilir.

Yukarıdaki ekran görüntüsünde, Google Chrome'un silme işlemlerini nasıl bildirdiğini görebilirsiniz. WebAuthn Signal API, masaüstünde Google Password Manager ile test edilebilir.

WebAuthn Signal API'yi etkili bir şekilde uygulamak ve istemci tarafı authenticator'lar arasında passkey meta verilerinin sorunsuz senkronizasyonunu sağlamak için aşağıdaki önerileri dikkate alın:

• WebAuthn Signal API güncellemelerini ve fiili uygulamaları takip edin: Signal API ile ilgili en son gelişmelerden ve güncellemelerden haberdar olun. WebAuthn Signal API, Google Chrome 132 ile etkinleştirildi, bunu diğer tarayıcılar takip ediyor (örneğin Safari de desteğini duyurdu). Uygulamanızın en son standartlar ve uygulamalarla uyumlu olduğundan emin olmak için WebAuthn Signal API'deki ilerlemeyi ve güncellemeleri düzenli olarak kontrol edin. Bu blog yazısını ekosistem geliştikçe güncelleyeceğiz.
• Her başarılı girişten sonra signalAllAcceptedCredentials(options) yaklaşımıyla başlayın: Bu yaklaşım, tüm meta verilerin ve kimlik bilgisi ID'lerinin tek bir yöntemle güncellenmesini sağlar, süreci basitleştirir, cihazlar ve platformlar arasında tutarlılığı korur ve aynı zamanda silinmiş veya eski kimlik bilgilerini devre dışı bırakır.
• Büyük ölçekli dağıtımlar için signalUnknownCredential(options) ile gerçek zamanlı mesajlaşma: Büyük ölçekli dağıtımlarda veya anında güncelleme ihtiyacı olduğunda signalUnknownCredential(options) yöntemiyle gerçek zamanlı mesajlaşmayı kullanmayı düşünün. Bu yöntem, kimlik bilgisi yönetiminin verimliliğini ve doğruluğunu artırabilir, geçersiz veya eski kimlik bilgilerinin seçim arayüzünden derhal kaldırılmasını sağlayabilir.

Bu önerileri takip ederek, desteklendiğinde WebAuthn Signal API'yi etkili bir şekilde uygulayabilir, passkey meta verilerinin tüm istemci tarafı authenticator'larda güncel ve tutarlı kalmasını sağlayabilir, böylece passkey'ler için sorunsuz ve güvenli bir kullanıcı deneyimi sunabilirsiniz.

WebAuthn standardı sürekli gelişiyor ve aylık bazda daha fazla özellik kazanıyor. WebAuthn Signal API'nin tanıtılması, istemci tarafı authenticator'larda passkey meta verilerini yönetme ve silme konusunda ileriye doğru atılmış önemli bir adımdır. Bu API, Relying Party'ler (RP'ler) ve authenticator'lar arasındaki bilgileri senkronize tutma ve geçersiz veya eski passkey'lerin kaldırılmasını sağlama gibi kritik kullanım durumlarını ele alarak kullanıcı deneyimini iyileştirir.

• Signal API'ye neden ihtiyaç var? Signal API, passkey meta verilerini güncellemek ve istemci tarafı authenticator'larda passkey'leri silmek için gereklidir. Kimlik bilgileri seçim arayüzünde sunulduğunda kafa karışıklığına neden olabilen eski user.name ve user.displayName bilgileriyle ilgili sorunları çözer. Ayrıca, iptal edilen veya silinen passkey'leri kaldırarak temiz ve güvenli bir kimlik bilgisi seçim arayüzü sağlamaya yardımcı olur.
• Signal API nasıl çalışır? Signal API, RP'lerin meta veri güncellemeleri ve passkey silme bildirimleri dahil olmak üzere kimlik bilgilerinin mevcut durumu hakkında yöntemler çağırmasına izin vererek çalışır. Bu bildirimler istemci tarafı authenticator tarafından işlenir ve kullanıcılara sunulan bilgilerin doğru ve güncel olması sağlanır. API, gizliliği koruyacak şekilde tasarlanmıştır ve güncellemelerin başarısı hakkında RP'ye geri bildirim sağlamadan çalışır.

WebAuthn standardı geliştikçe, standardın farklı bölümlerini ileriye taşıyan katılımcılarının çeşitli ilgi alanlarından faydalanır. Bu gelişmeleri takip etmek, en son iyileştirmelerden haberdar olmak ve uygulamaların en son en iyi uygulamalar ve standartlarla uyumlu kalmasını sağlamak için çok önemlidir. WebAuthn topluluğu inovasyonu sürdürmeye devam ederek kimlik doğrulamayı daha güvenli ve kullanıcı dostu hale getiriyor.