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

Passkey ekosistemi sürekli gelişiyor. Bu değişimi kolaylaştırmak için temelindeki WebAuthn standardı da hızla evriliyor. Yeni özellikler genellikle GitHub'da teknik bir açıklama ile başlar ve yeterince tartışıldıktan sonra standarda yönelik bir pull request'e dönüşür. Yakın zamanda, bu pull request standart taslağına WebAuthn Signal API olarak eklendi. Bu makalede şu konuları ele alacağız:

• WebAuthn Signal API neden gerekli: WebAuthn Signal API hangi kullanım senaryolarını destekliyor?
• WebAuthn Signal API nasıl çalışır: WebAuthn Signal API tam olarak nasıl çalışır? Dayanak taraflar için öneriler nelerdir?

Bu blog yazısını güncellediğimiz Ocak 2025 itibarıyla, WebAuthn Signal API, Chrome 132'den beri varsayılan olarak etkindir ve daha önce aynı ada sahip başka bir API ile çakışmaları önlemek için yeniden adlandırılmadan önce Reporting API olarak biliniyordu.

WebAuthn Signal API, passkey'lerin istemci tarafında yönetimiyle ilgili belirli kullanım senaryolarını ele alır. Özellikle, dayanak taraf (relying party) (RP) ile istemci tarafı işletim sistemlerinin bir parçası olan doğrulayıcılar (authenticators) arasındaki bilgilerin senkronize kalmasına yardımcı olur. Aşağıdaki önemli kullanım senaryoları mevcuttur:

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Bir passkey oluşturulduğunda, user.id, user.name ve user.displayName gibi çeşitli bilgiler içerir. Passkey'in kendisi, benzersiz Kimlik Bilgisi ID'si (Credential ID) ile tanımlanır.

• user.id: passkey'in bağlı olduğu hesabı temsil eden benzersiz bir tanımlayıcıdır. Bu user.id kritik öneme sahiptir çünkü passkey'in kullanıcının hesabıyla eşleştirilmesi 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 çizim, hangi bilginin genellikle hangi alanda saklanacağını açıklayan tipik, basit bir veritabanı yapısını göstermektedir:

user.name (genellikle bir e-posta adresi) ve user.displayName (daha kolay okunabilir, samimi bir ad) kullanıcının seçim arayüzünde hesabını tanımasına yardımcı olurken, bir passkey ile bir hesap arasındaki asıl bağlantının user.id ve Kimlik Bilgisi ID'si aracılığıyla sağlandığını anlamak önemlidir:

• Bir hesabın birden fazla passkey'i olabilir, ancak her passkey benzersiz olarak tanımlanır ve user.id kullanılarak hesapla eşleştirilir.
• Her passkey'in kendisi, doğrulayıcı tarafından oluşturulan benzersiz bir Kimlik Bilgisi ID'sine sahiptir.

Bir sorun, bir e-posta adresi olabilen user.name değiştiğinde ortaya çıkar. Şu anda, bu değişikliği doğrudan istemci tarafındaki doğrulayıcıda güncellemek için bir mekanizma yoktur. user.name, bir kullanıcının e-posta adresini güncellemesi gibi ç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 arayüzünde 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ı kullanışsızdır:

1. Gereksizlik: Her user.id, dayanak taraf (relying party) ID'si başına yalnızca bir passkey'e sahip olabilir, bu da eski passkey'in yeni bir tanesiyle değiştirilmesi gerektiği anlamına gelir ki bu da fazladan 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 işlemlerini 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'i doğrudan doğrulayıcıda güncellemek için basit bir yöntem olmadan, kullanıcılar eski e-posta adresleriyle ilişkili bir passkey'i görüp seçmek zorunda kaldıkları kalıcı bir sorunla karşılaşabilirler. Bu durum, passkey'lerin sağlamayı amaçladığı sorunsuz deneyimi zayıflatır. WebAuthn Signal API, dayanak tarafların yeni passkey oluşturmayı gerektirmeden passkey'lerin meta verilerindeki güncellemeleri bildirmesine olanak tanıyarak bu sorunu çözmeyi amaçlamaktadır. Signal API'nin nasıl uygulanacağını açıklamadan önce, ele aldığı ikinci önemli kullanım senaryosunu inceleyeceğiz.

Become part of our Passkeys Community for updates & support.

Join

Bir diğer önemli kullanım senaryosu, istemci tarafındaki doğrulayıcıda passkey'lerin silinmesidir. Zamanla, kullanıcılar passkey yönetim listesi aracılığıyla kimlik bilgilerini iptal edebilir veya hesaplarını silebilirler ve bu kimlik bilgilerinin gelecekteki kimlik bilgisi seçim arayüzlerinde (Koşullu Arayüz (Conditional UI) / passkey otomatik doldurma) görünmesini önlemek için istemci tarafındaki doğrulayıcıdan kaldırıldığından emin olmak gerekir.

Bu işlevselliğe olan ihtiyaç birkaç senaryoda ortaya çıkar:

1. Hesap ayarları aracılığıyla silinen passkey: Bir kimlik bilgisi, kullanıcının hesap ayarları aracılığıyla açıkça sildikten sonra artık geçerli olmadığında:

Kullanıcı açısından, yukarıdaki gibi bir diyalogda, hesap ayarlarındaki bir silme işleminin bu istemcideki passkey'in 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ı: Dayanak tarafların, hareketsizlik dönemlerinden sonra veya tespit edilen güvenlik sorunları nedeniyle kimlik bilgilerinin iptal edilmesini gerektiren güvenlik politikaları olabilir.

İstemci tarafında passkey'leri silmek için doğrudan bir yöntem olmadan, 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 denemelerine ve kötü bir kullanıcı deneyimine neden olur.

WebAuthn Signal API'nin uygulanması, işlevselliğin doğru ve güvenli bir şekilde entegre edilmesini sağlamak için birkaç adım ve dikkat edilmesi gereken husus içerir. Signal API, dayanak tarafların (RP'ler) istemci tarafındaki doğrulayıcıda 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, istenen değişikliğin işlenip işlenmediği konusunda RP'ye herhangi bir geri bildirim sağlanmadığı anlamına gelir. API, kimlik bilgilerinin durumu hakkında herhangi bir potansiyel bilgi sızıntısını önlemek için sessizce çalışır.

• Doğrulayıcı Erişilebilirliği: WebAuthn Signal API'nin etkinliği, doğrulayıcının erişilebilirliğine bağlıdır. Bu, hem fiziksel erişilebilirliği (örneğin, bir güvenlik anahtarının varlığı) hem de yazılım desteğini (örneğin, tarayıcı ve işletim sistemi uyumluluğu) içerir. Tarayıcı, yalnızca doğrulayıcı erişilebilir durumdaysa ve biyometrik kimlik doğrulaması gerektirmeden gerekli işlemleri destekliyorsa eylemleri gerçekleştirebilir.

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

• Anahtar Olarak Kimlik Bilgisi ID'si: Passkey'lere atıfta bulunurken, Kimlik Bilgisi ID'si WebAuthn Signal API tarafından kullanılan birincil anahtardır. Bu ID, istemci tarafındaki doğrulayıcıda 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 olanak tanır, ancak bunu yalnızca Kimlik Bilgisi ID'si aracılığıyla yapar. Bir doğrulayıcının belirli bir Kimlik Bilgisi ID'sini tanımaması durumunda, onu sessizce görmezden gelecektir.

Bu hususlar, WebAuthn Signal API'nin en önemli yönlerinin doğru şekilde çalışmasını anlamak için gereklidir.

WebAuthn Signal API, dayanak tarafların (RP'ler) istemci tarafındaki doğrulayıcılarda passkey'lerle ilişkili meta verileri güncellemesi için modern 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) metodu, özellikle passkey'lerin meta verilerini güncellemek için tasarlanmıştır. Bu metot, RP'lerin user.name ve user.displayName için güncel değerleri sağlamasına olanak tanır.

İşte sürecin nasıl işlediği (ayrıca WebAuthn Seviye 3 standardına da bakınız).

1. Metot Yapısı: signalCurrentUserDetails(options) metodu, rp.id, user.id ve user.name ile user.displayName için güncellenmiş değerleri içerir.

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    name: "New user name",
    displayName: "New display name",
});

2. Yerel Meta Verileri Güncelleme: Yerel olarak (doğrulayıcıda) bulunan ve rpId ile userId ile eşleşen kimlik bilgilerini arar. Eşleşen tüm kimlik bilgileri için doğrulayıcı, 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 konusunda RP'ye geri bildirim sağlamaz, bu da kimlik bilgilerinin durumu hakkında herhangi bir bilgi sızıntısını önler.

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

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

WebAuthn Signal API, dayanak tarafların (RP'ler) istemci tarafındaki doğrulayıcılardan passkey'lerin silinmesini bildirmesi için mekanizmalar sağlar. Bu, eski veya geçersiz kimlik bilgilerinin kimlik bilgisi seçim arayüzünde görünmemesini sağlayarak modern ve güvenli bir kullanıcı deneyimi sürdürmek için gereklidir. Passkey'leri yerel olarak silmek için iki metot vardır: signalUnknownCredential(options) ve signalAllAcceptedCredentials)(options). İlki, kullanıcının kimliği doğrulanmadığı durumlarda kullanılabilirken, ikincisi kullanıcı kimliği doğrulandığında kullanılabilir. Bu nedenle, gizlilik nedenleriyle ikincisi tercih edilmelidir.

İşte iki metodun nasıl çalıştığı:

1. Metot Yapısı: signalUnknownCredential(options) metodu, rpId (dayanak taraf ID'si) ve credentialId (silinecek kimlik bilgisinin benzersiz tanımlayıcısı) içerir.

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc", // credential id the user just tried, base64url
});

2. Metodu Çağırma: RP'ler, bir kimlik bilgisinin silinmesi gerektiğini tespit ettiklerinde bu metodu çağırır. Bu, geçersiz bir kimlik bilgisiyle yapılan bir kimlik doğrulama denemesinin 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. Metodu İşleme: signalUnknownCredential(options) metodu çağrıldığında, istemci tarafındaki doğrulayıcı, atlanması için belirtilen rpId ve credentialID ile eşleşen kimlik bilgilerini bulmaya çalışır. Doğrulayıcının yeteneklerine bağlı olarak, kimlik bilgisi kaldırılır veya gelecekteki kimlik doğrulama törenlerinde kimlik bilgisini gizlemek için doğrulayıcıya özgü bir prosedür kullanılır.

1. Metot Yapısı: signalAllAcceptedCredentials(options) metodu, rpId (dayanak taraf ID'si), userId ve geçerli Kimlik Bilgisi ID'lerinin bir listesini (allAcceptedCredentialIds - saklanması gereken kimlik bilgilerinin benzersiz tanımlayıcılarının listesi) içerir.

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    allAcceptedCredentialIds: ["bb"],
});

2. Metodu Çağırma: RP'ler, bir kimlik bilgisinin silinmesi gerektiğini tespit ettiklerinde ve geçerli kimlik bilgileri listesini bildirdiklerinde bu metodu çağırır. Kimlik bilgilerini silmek için bu metot, signalUnknownCredential(options)'a tercih edilmelidir.

3. Metodu İşleme: signalAllAcceptedCredentials(options) metodu çağrıldığında, istemci tarafındaki doğrulayıcı rpId ve userId'yi eşleştirir. Doğrulayıcı, rpId ve userId ile eşleşen tüm yerel kimlik bilgilerini arar. Sonuç, allAcceptedCredentialIds ile karşılaştırılır. allAcceptedCredentialIds içinde olmayan yerel kimlik bilgileri varsa, bu kimlik bilgileri yerel olarak kaldırılır (veya doğrulayıcıya bağlı olarak gizlenir).

4. Kimlik Bilgilerini Göster: Eğer kimlik bilgileri yalnızca gizlenmişse (doğrulayıcıya bağlı olarak) ve şimdi allAcceptedCredentialIds'in bir parçasıysa, bu kimlik bilgileri gelecekteki kimlik doğrulama törenlerinde tekrar mevcut olacaktır.

5. Faydalı İpuçları:

   • signalAllAcceptedCredentials(options) kullanırken, bu metot yürütüldüğünde doğrulayıcıların her zaman bağlı olmayabileceğini unutmamak önemlidir. Sonuç olarak, dayanak taraflar tüm kimlik bilgilerinin güncel olduğundan emin olmak için signalAllAcceptedCredentials(options)'ı periyodik olarak, örneğin her oturum açmada çalıştırmayı düşünebilirler.
   • Dayanak taraflar, kimlik bilgisi ID'leri listesini (allAcceptedCredentialIds) belirtirken dikkatli olmalıdır. Bu listede yer almayan kimlik bilgileri, doğrulayıcı tarafından potansiyel olarak geri döndürülemez bir şekilde gizlenebilir veya kaldırılabilir. Geçerli kimlik bilgilerinin yanlışlıkla atlanmasını önlemek için listenin eksiksiz olduğundan emin olmak çok önemlidir. Geçerli bir kimlik bilgisi ID'si yanlışlıkla dışarıda bırakılırsa, doğrulayıcının bunu desteklediği varsayılarak tekrar görünür hale getirmek için mümkün olan en kısa sürede signalAllAcceptedCredentials(options)'a yeniden eklenmelidir.
   • Mümkün olduğunda, doğrulayıcılar kimlik bilgilerini kalıcı olarak kaldırmak yerine geçici olarak gizlemeyi tercih etmelidir. Bu yaklaşım, dayanak taraf tarafından yanlışlıkla atlanan geçerli bir kimlik bilgisi ID'sinin kurtarılmasına yardımcı olabilir ve kalıcı kayıp olmadan geri yüklenmesine olanak tanır.

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

WebAuthn Signal API'yi etkili bir şekilde uygulamak ve passkey meta verilerinin istemci tarafı doğrulayıcılar arasında sorunsuz bir şekilde senkronize edilmesini sağlamak için aşağıdaki önerileri göz önünde bulundurun:

• WebAuthn Signal API güncellemelerini ve fiili uygulamaları takip edin: Signal API ile ilgili en son gelişmeler ve güncellemeler hakkında bilgi sahibi olun. WebAuthn Signal API, Google Chrome 132 ile etkinleştirilmiştir ve diğer tarayıcılar da (örneğin, Safari de destek duyurdu) bunu takip edecektir. 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ı gelecekte güncelleyeceğiz, şu anda 14 Ocak 2025'ten itibaren mevcut olan bilgilere dayanmaktadır.
• 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 metotta güncellenmesini sağlar, süreci basitleştirir ve cihazlar ile platformlar arasında tutarlılığı korurken 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) metoduyla gerçek zamanlı mesajlaşmayı kullanmayı düşünün. Bu metot, 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ğlar.

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

WebAuthn standardı sürekli olarak gelişiyor ve her ay daha zengin özelliklere sahip oluyor. WebAuthn Signal API'nin tanıtılması, istemci tarafı doğrulayıcılarda passkey meta verilerini yönetme ve silme işlemlerinde ileriye doğru atılmış önemli bir adımdır. Bu API, dayanak taraflar (RP'ler) ve doğrulayıcılar arasındaki bilgileri senkronize tutma ve geçersiz veya eski passkey'lerin kaldırılmasını sağlayarak kullanıcı deneyimini iyileştirme gibi kritik kullanım senaryolarını ele alır.

• Signal API neden gerekli? Signal API, istemci tarafı doğrulayıcılarda passkey meta verilerini güncellemek ve passkey'leri silmek için gereklidir. Eski user.name ve user.displayName bilgileriyle ilgili sorunları çözer, bu da kimlik bilgileri seçim arayüzünde sunulduğunda kafa karışıklığına neden olabilir. Ek olarak, iptal edilmiş veya silinmiş 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'lerin silinmesini bildirme dahil olmak üzere kimlik bilgilerinin mevcut durumu hakkında metotları çağırmasına izin vererek çalışır. Bu raporlar istemci tarafı doğrulayıcı tarafından işlenir ve kullanıcılara sunulan bilgilerin doğru ve güncel olmasını sağlar. 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 geliştirmelerle güncel kalmak ve uygulamaların en son en iyi uygulamalar ve standartlarla uyumlu kalmasını sağlamak için çok önemlidir. WebAuthn topluluğu, kimlik doğrulamayı daha güvenli ve kullanıcı dostu hale getirerek yeniliği teşvik etmeye devam ediyor.