WebAuthn Resident Key: Passkey Olarak Keşfedilebilir Kimlik Bilgileri

Passkeys ve temelindeki WebAuthn protokolü, kimlik doğrulama dünyasında devrim yaratıyor. Ancak, bir WebAuthn sunucusunu doğru şekilde kurmak zorlu bir iş olabilir. Yanlış yapılandırmalar yalnızca güvenlik açıkları oluşturmakla kalmaz, aynı zamanda daha sonra değiştirmeniz gerektiğinde mevcut passkey'leri de bozabilir. Bu blog yazısı, genellikle karmaşık olan WebAuthn özelliklerini daha iyi anlamanıza yardımcı olacak ve kendi kullanım durumunuz için en iyi ayarların ne olduğu konusunda tavsiyeler sunacaktır.

WebAuthn üç ana varlıkla çalışır:

• Güvenen Taraf (Relying Party - RP): Bu, bir kullanıcıyı doğrulamak isteyen web hizmetimizdir. İstemciye zorluk (challenge) gönderir, yanıtları doğrular ve bir passkey'in açık anahtarını yönetir.
• Doğrulayıcılar (Authenticators): Bunlar, bir kimlik bilgisine sahip olunduğunu kanıtlayabilen cihazlardır. Örnek olarak akıllı telefonlar, dizüstü bilgisayarlar veya güvenlik anahtarları (örneğin, YubiKeys) verilebilir. Doğrulayıcılar platforma özgü (Windows Hello veya Apple'ın Touch ID / Face ID'si gibi) veya platformlar arası (güvenlik anahtarları gibi, örn. YubiKeys) olabilir.
• İstemciler (Clients): Genellikle, bunlar RP ve doğrulayıcı arasında aracı olarak hareket eden web tarayıcıları veya yerel uygulamalardır. Verilerin doğru ve güvenli bir şekilde akmasını sağlayarak iletişimi kolaylaştırırlar.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

Aşağıda, bir kimlik doğrulama süreci (oturum açma veya kaydolma) sırasındaki üst düzey veri akışı açıklanmaktadır.

1. İstemci Başlatması: Süreç, genellikle bir kullanıcının oturum açmaya veya kaydolmaya çalışmasıyla istemci tarafında başlar. Örneğin, "WebAuthn ile Giriş Yap" düğmesine tıklayabilirler ve istemci, RP'ye bir zorluk (challenge) talebi gönderir.
2. RP İsteği: RP daha sonra istemciye bir zorluk (challenge) geri gönderir. Bu zorluk, sonraki yanıtın gerçekliğini sağlayan rastgele oluşturulmuş bir değerdir.
3. İstemciden Doğrulayıcıya: Kaydolma sırasında, istemci doğrulayıcıdan ilgili açık-özel anahtar çiftini oluşturarak yeni bir passkey oluşturmasını ister. Oturum açma sırasında, istemci doğrulayıcıdan zorluğu imzalamasını ister. Bu, doğrulayıcıdaki özel anahtar kullanılarak yapılır ve bu anahtar, daha önce RP'de saklanan kayıtlı bir açık anahtara karşılık gelir.
4. Doğrulayıcı Yanıtı: Kaydolma sırasında, doğrulayıcı açık anahtarı istemciye geri gönderir. Oturum açma sırasında, doğrulayıcı zorluğu imzalar ve bu imzalanmış onaylamayı (assertion) istemciye geri gönderir.
5. İstemciden RP'ye: İstemci, bu yeni açık anahtarı / imzalanmış onaylamayı (assertion) RP'ye iletir.
6. RP Doğrulaması: RP, açık anahtarı saklar / imzalanmış onaylamayı (assertion) saklanan açık anahtarı kullanarak doğrular. Eğer geçerliyse, kimlik doğrulama başarılı olur.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

10.000'den fazla geliştirici Corbado'ya güveniyor ve passkey'ler ile interneti daha güvenli hale getiriyor. Sorularınız mı var? Passkey'ler üzerine 150'den fazla blog yazısı yazdık.

Passkeys Topluluğuna Katılın

Yukarıda açıklanan üst düzey süreç akışı, WebAuthn kaydolma ve oturum açma süreçlerini tanımlar. Passkey'ler, WebAuthn üzerine inşa edilmiştir. Başlangıçta passkey terimi, WebAuthn'dan daha akılda kalıcı ve teknik olmayan bir terim olarak aynı şeyi tanımlamak için kullanılıyordu. Ayrıca, passkey'ler standart WebAuthn'a kıyasla daha fazla özellik sunar, örneğin passkey'leri bulut hesapları veya parola yöneticileri aracılığıyla senkronize etme imkanı.

Sonraki bölümleri daha iyi anlamak için, WebAuthn protokolündeki bazı önemli terimleri ortak bir anlayışa sahip olmak adına tanımlayalım.

• Kimlik Bilgisi ID'si (Credential ID): Credential ID, bir doğrulayıcı tarafından oluşturulan belirli bir açık anahtar kimlik bilgisine atanan benzersiz bir tanımlayıcıdır. Güvenen Tarafların (RP'ler), kimlik doğrulama süreçleri için doğru PublicKeyCredential'ı tanımlamasına ve seçmesine olanak tanır.
• PublicKeyCredential: Bu, tarayıcının veya yerel uygulamaların WebAuthn API'sinden döndürülen birincil veri yapısıdır. Hem kaydolma sırasındaki Attestation verilerini hem de oturum açma sırasındaki Assertion verilerini kapsar. Esasen, RP'nin süreci doğrulamak için ihtiyaç duyduğu verileri içerir.
• Attestation: WebAuthn bağlamında Attestation, doğrulayıcının kökeninin ve bütünlüğünün bir kanıtı olarak hizmet eder. Kaydolma sırasında, doğrulayıcının "Kullanıcının kimlik bilgisini güvenli bir şekilde kaydettim ve işte bunu doğrulamanız için kullanabileceğiniz bir beyan" demesinin bir yoludur. Güvenen Taraf daha sonra imzanın izin verilen belirli bir doğrulayıcıdan (örneğin, Yubikey) geldiğini doğrulayabilir. Tüm passkey doğrulayıcıları böyle bir attestation ile yanıt vermez, bazıları sadece yararlı veri geri göndermez (passkey doğrulayıcılarının listesi için buraya bakın). Daha fazla doğrulayıcıyı (özellikle güvenlik anahtarları, örn. YubiKeys) tanımlayan AAGUID'ler (Authenticator Attestation GUIDs) FIDO Alliance Metadata Service içinde bulunabilir.
• Assertion: Kaydolma işleminden sonra, bir kullanıcı oturum açmaya çalıştığında, doğrulayıcı bir onaylama (assertion) üretir. Assertion temel olarak PublicKeyCredential + imzalanmış zorluktur. Bu assertion, kullanıcının gerçek özel anahtarı ifşa etmeden kayıtlı açık anahtarla bağlantılı özel anahtara sahip olduğunu kanıtlar. Bu, doğrulayıcının "Bu gerçek kullanıcı ve ben onlara kefil olabilirim" demesinin bir yoludur.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Resident key'ler (RKs) ve non-resident key'ler (NRKs), WebAuthn protokolünde kullanılan iki tür kriptografik anahtardır ve temel olarak depolama konumları ve geri alma mekanizmalarında farklılık gösterirler.

Tanım:

Resident key'ler doğrudan doğrulayıcının kendisinde saklanır. Bu bir güvenlik anahtarı (örneğin, YubiKey), bir platformun güvenli bölgesi (örneğin, iPhone'un Secure Enclave) veya bir dizüstü bilgisayardaki güvenilir platform modülü (TPM) olabilir. Koşullu Arayüz (passkey otomatik doldurma) yalnızca resident key'ler için çalışır ve WebAuthn çalışma grubu şu anda bir anahtarın passkey olarak kabul edilmesi için resident key olmasını gerektirmektedir.

Bir sonraki ekran görüntüsünde, bir YubiKey üzerinde depolanan tüm resident key'lerin (kimlik bilgisi ID'si, rpID, kullanıcı adı, görünen ad) bir listesini görüyorsunuz. Non-resident key'ler listede yer almaz, çünkü doğrulayıcıda depolanmazlar:

Oturum açma akışı:

Kaynak: William Brown

Oturum açma işlemi sırasında, Güvenen Taraf istemciye (tarayıcı) kimlik bilgisi belirtmeden bir istek gönderir ve istemci doğrulayıcıyı sorgulamaya başlar (buradaki şemada: güvenlik anahtarı). Doğrulayıcı, ilgili Güvenen Taraf için tüm resident key'leri keşfeder ve istemci (tarayıcı) istenen resident key'i seçer. Bu resident key, zorluğu imzalamak için kullanılır. İmza, doğrulayıcıdan istemci aracılığıyla Güvenen Tarafa gönderilir.

Avantajları:

1. Kolaylaştırılmış Kullanıcı Deneyimi: Resident key'lerin en önemli avantajlarından biri, doğrulayıcının kullanıcı tanıtıcısını (örneğin, e-posta, telefon numarası, kullanıcı adı) saklaması ve böylece giriş için kullanıcı tanıtıcısını (örneğin, e-posta, telefon numarası, kullanıcı adı) önceden doldurabilmesidir. Kullanıcıların kullanıcı tanıtıcılarını (örneğin, e-posta, telefon numarası, kullanıcı adı) hatırlamasına veya girmesine gerek kalmaz, bu da özellikle biyometrik özelliklere sahip cihazlarda oturum açma sürecini kolaylaştırır. Bu, Koşullu Arayüz ile otomatik olarak da gerçekleşebilir.
2. Cihaza Özgü Kimlik Doğrulama: Resident key'ler, kimlik doğrulamayı belirli bir cihaza bağlayarak ek bir güvenlik katmanı sağlayabilir. Bu, özellikle kullanıcıların güvenilir cihazlardan giriş yapmasını sağlamak isteyen hizmetler için yararlı olabilir.
3. Koşullu Arayüz (Passkey Otomatik Doldurma): Koşullu Arayüz yalnızca en sorunsuz oturum açma deneyimini sağlayan resident key'lerle çalışır (ayrıntılar için aşağıya bakın).

Dezavantajları:

1. Depolama Sınırlaması: Bazı doğrulayıcıların sınırlı bir depolama kapasitesi vardır. Özellikle güvenlik anahtarları (örneğin, YubiKey'ler) için, depolayabilecekleri resident key sayısında genellikle bir sınır vardır (çoğunun sınırı 8 ila ~100 resident key arasında değişir). Bu sınıra ulaşıldığında, yenilerine yer açmak için eski anahtarların silinmesi gerekebilir veya kullanıcının başka bir doğrulayıcı kullanması gerekebilir.
2. Doğrulayıcının Kaybı: Doğrulayıcı, örneğin bir güvenlik anahtarı (örn. YubiKey) veya akıllı telefon kaybolur veya hasar görürse, o cihazdaki tüm resident key'ler kaybolur. Bu, kullanıcıların hesaplarını yeniden kaydettirene veya kurtarana kadar birden fazla hizmetten dışlanmasına neden olabilir. Anahtarları bir bulut hesabı (örneğin, iCloud Anahtar Zinciri, Google Şifre Yöneticisi) veya modern bir şifre yöneticisi (örneğin, 1Password veya Dashlane) aracılığıyla senkronize etmek bu kaybı önler.
3. Güvenlik Endişeleri: Resident key'lere sahip bir doğrulayıcı çalınırsa, bir saldırgan anahtarları çıkarmaya çalışabilir. Modern doğrulayıcılar çıkarmayı önlemek için sağlam güvenlik mekanizmalarına sahip olsa da, örneğin kullanıcının cihazı güçlü bir PIN, parola veya hareketle koruması gibi, risk, minimal de olsa, hala mevcuttur.

Kullanım Alanları: Kişisel akıllı telefonlar veya dizüstü bilgisayarlar gibi kullanıcının sık sık kimlik doğruladığı cihazlar için idealdir.

Want to find out how many people use passkeys?

View Adoption Data

Tanım:

Non-resident key'ler, aksine, doğrulayıcıda saklanmaz. Bunun yerine, doğrulayıcı yeni bir anahtar çifti oluşturur (dahili olarak korunan ana anahtarına dayanarak) ve bu yeni anahtar çiftinin açık anahtarını, kimlik bilgisi ID'si (bir tohum - seed içeren) ile birlikte sunucuya (Güvenen Taraf) gönderir. Sunucu daha sonra bu açık anahtarı kullanıcının hesabıyla ilişkilendirir. Sonraki kimlik doğrulamalar için, doğrulayıcı, kimlik bilgisi ID'sini alarak, tohumu çıkararak ve ana anahtarla birleştirerek özel anahtarı yeniden türetir. Anahtar yalnızca doğrulayıcının korumalı belleğinde geçici olarak mevcut olduğu için kriptografik dilde bazen geçici anahtar (ephemeral key) olarak adlandırılır.

Oturum açma akışı:

Kaynak: William Brown

Oturum açma işlemi sırasında, Güvenen Taraf öncelikle hangi kullanıcının kimlik doğrulaması istediğini tanımlamalıdır (örneğin, bir kullanıcı tanıtıcısı - e-posta, telefon numarası veya kullanıcı adı - isteyerek) ve ardından istekte bulunan kullanıcı için bildiği kimlik bilgisi ID'lerini istemciye (tarayıcı) gönderir. İstemci bunları doğrulayıcıya (burada: güvenlik anahtarı) iletir. Doğrulayıcı, geçici özel anahtarı türetmek için doğrulayıcının ana anahtarıyla birlikte kimlik bilgisi ID'sini kullanır, zorluğu oluşturulan anahtarla imzalar ve istemciye (burada: tarayıcı) geri gönderir, o da bunu Güvenen Tarafa iletir. Non-resident key'ler, passkey'lerin tanıtımından önce başlangıçta ikinci faktör olarak kullanılıyordu. Bu nedenle, önce kullanıcıyı tanımlamak normal oturum açma sürecinin bir parçasıydı.

Avantajları:

1. Ölçeklenebilirlik: Non-resident key'ler doğrulayıcıda bulunmadığından, kullanıcılar çeşitli hizmetlerle ilişkili neredeyse sınırsız sayıda non-resident key'e sahip olabilirler. Bu, özellikle çok sayıda platformda hesabı olan kullanıcılar için faydalıdır.
2. Dolaşım Yeteneği: Non-resident key'ler, güvenlik anahtarları (örneğin, YubiKey) gibi dolaşımdaki doğrulayıcılar için idealdir. Bir kullanıcı, birden fazla cihaz ve platformda kimlik doğrulamak için aynı güvenlik anahtarını (örneğin, YubiKey) kullanarak tutarlı bir deneyim sağlayabilir.
3. Doğrulayıcı Depolamasına Azaltılmış Bağımlılık: Uygun WebAuthn sunucu ayarları için, doğrulayıcının depolama sınırlamaları hakkında endişelenmenize gerek yoktur. Bu, özellikle güvenlik anahtarları (örneğin, YubiKey'ler) gibi düşük depolama kapasiteli doğrulayıcılar için avantajlı olabilir.

Dezavantajları:

1. Kullanıcı Tanıtıcısı Gerektirdiği İçin Daha Az Kullanıcı Deneyimi: Non-resident key'lerin en büyük dezavantajı, kullanıcının kullanıcı tanıtıcısını (örneğin, e-posta, telefon numarası, kullanıcı adı) sağlaması gerekmesidir, bu da Koşullu Arayüz aracılığıyla bir kullanıcı adı ön doldurmasını imkansız hale getirir. Bu kullanıcı tanıtıcısının, geçici anahtar sarmalanmış anahtarı hesaplamak için gereken kimlik bilgisi ID'sine bağlanması gerekir.
2. Potansiyel Yanlış Yönetim: RP'ler, kullanıcı hesapları ve açık anahtarlar arasındaki ilişkileri yönetmeli ve güvence altına almalıdır. Kötü yönetim veya güvenlik açıkları güvenlik sorunlarına yol açabilir.

Kullanım Alanları: Birden fazla hizmet veya platformda kullanılan güvenlik anahtarları (örneğin, YubiKey'ler) gibi dolaşımdaki doğrulayıcılar için idealdir.

Bir güvenlik anahtarınız (örneğin, YubiKey) olduğunu ve bunu iki çevrimiçi hizmetle kaydettirdiğinizi hayal edin: Hizmet A ve Hizmet B. Hizmet A için bir resident key kullanıyorsunuz. Hizmet B için ise bir non-resident key. Hizmet A'ya kimlik doğruladığınızda, sadece güvenlik anahtarınıza (örneğin, YubiKey) dokunursunuz ve giriş yaparsınız - kullanıcı adı belirtmenize gerek kalmaz. Hizmet B için ise, önce tarayıcıda / yerel uygulamada kullanıcı adınızı sağlarsınız. Hizmet daha sonra ilgili kimlik bilgisi ID'sini güvenlik anahtarınıza (örneğin, YubiKey) gönderir, bu da kimlik doğrulama için geçici özel anahtarı yeniden oluşturur.

Özünde, hem resident hem de non-resident key'ler kriptografik kimlik doğrulamadan yararlanarak güvenliği artırırken, kullanıcı deneyimleri ve depolama mekanizmaları farklılık göstererek çeşitli kullanım durumlarına hitap eder.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

Koşullu Arayüz, passkey'lerin / WebAuthn'ın bir dönüm noktası özelliğidir. Kullanıcıdan daha da fazla yük alır, çünkü kullanıcı sadece bir şifre hatırlamak zorunda kalmaz, aynı zamanda bir Güvenen Tarafa kaydolduğu kullanıcı tanıtıcısını (örneğin, e-posta, telefon numarası, kullanıcı adı) da hatırlamak zorunda kalmaz. Özellikle, Güvenen Tarafların hizmetlerinin yalnızca ara sıra kullanıldığı durumlarda bu büyük bir adımdır.

Bu, giriş sayfası açılır açılmaz, Güvenen Taraf sunucusunun arka planda istemciye bir zorluk göndermesiyle çalışır (bu çağrıda gönderilmesi gereken bir kimlik bilgisi ID'si olmadığını unutmayın). İstemci bu zorluğu alır ve bu doğrulayıcıdaki Güvenen Taraf ID'siyle hangi passkey'lerin eşleştiğini kontrol eder ve kullanıcıya uygun passkey'i seçebileceği otomatik doldurma menüsü aracılığıyla seçimi sunar.

Üstelik, kullanıcıyı giriş düğmesine fazladan bir tıklamadan da kurtarır, çünkü passkey otomatik doldurma menüsünden seçilir seçilmez giriş işlemi başlar.

CTAP, FIDO2 standardında temel bir protokoldür ve istemciler (tarayıcılar gibi) ile doğrulayıcılar (güvenlik anahtarları, örn. YubiKey'ler veya akıllı telefonlar gibi) arasındaki iletişim boşluğunu doldurur. CTAP'ı daha iyi anlamak için, resident ve non-resident key'ler üzerindeki etkisini analiz etmeden önce farklı protokol sürümlerine kısa bir göz atalım.

Genellikle Evrensel 2. Faktör (U2F) olarak adlandırılan daha önceki sürüm, öncelikle ikinci faktör kimlik doğrulaması için tasarlanmıştı. U2F'de, sunucu bir zorluk sağlar ve doğrulayıcı, özel anahtara sahip olduğunu kanıtlayan bir yanıt verir. Ancak, U2F resident key'leri desteklemez, yani bir kullanıcı için hangi anahtarın kullanılacağını belirlemek için her zaman sunucu tarafında bir arama gerektirir, çünkü bu ikinci bir faktör istendiğinde sürecin bir parçasıydı.

U2F'nin halefi olan CTAP2, resident key'ler için destek sunarak şifresiz ve kullanıcı adısız kimlik doğrulamasına olanak tanıdı. Resident key'lerle, doğrulayıcı kullanıcının kullanıcı adını ve kimlik bilgisi ID'sini ( Güvenen Taraf ID'si ile birlikte) saklar, bu da Güvenen Taraf sunucusunun kimlik doğrulama sırasında bunu sağlaması gerekliliğini ortadan kaldırır. Bu, daha sorunsuz bir kullanıcı deneyimine doğru önemli bir adımdır.

Ancak, CTAP2 zorluklarla birlikte gelir. Dikkate değer bir sorun, resident key'lerin yönetimidir. Örneğin, bir CTAP2.0 cihazında belirli bir resident key'i silmek genellikle tam bir cihaz sıfırlaması gerektirir (yani ana anahtarınız da sıfırlanır, bu da tüm non-resident key'lerinizin artık çalışmayacağı anlamına gelir), bu kullanıcı dostu değildir ve tek bir cihazda birden fazla resident key'in saklandığı senaryolarda sorunlu olabilir. Bu, bir CTAP2.0 cihazındaki resident key'leri ciddi bir taahhüt haline getirir. Özellikle güvenlik anahtarlarında (örneğin, YubiKey'ler) sıkça sahip olduğunuz o sınırlı alanı yanlışlıkla doldurmak istemezsiniz.

CTAP2.1, CTAP2'nin bir sonraki sürümüdür ve protokole ek özellikler ve iyileştirmeler getirir. CTAP 2.1 ile ilgili bazı önemli noktalar şunlardır:

• Daha İyi Resident Key Yönetimi: CTAP 2.1, cihazınızdaki belirli resident key'leri bireysel olarak yönetmenize, güncellemenize ve silmenize olanak tanır.
• Kurumsal Attestation: Bu özellik, işletmelerin çalışanları tarafından kullanılan anahtarlar üzerinde daha fazla kontrole sahip olmalarını sağlar. İşletmelerin kullanılan anahtarların şirket tarafından verildiğini doğrulaması için bir yol sunar.
• Çoklu Kullanıcı Tanıma: Bazı doğrulayıcılar birden fazla kullanıcıyı tanıyabilir. CTAP 2.1, bu doğrulayıcıların hangi kullanıcının tanındığını belirtmesi için bir yol sağlar.
• Geriye Dönük Uyumluluk: CTAP 2.1, CTAP2 ile geriye dönük uyumlu olacak şekilde tasarlanmıştır, bu da eski sürümü destekleyen cihazların ve platformların yenisiyle hala çalışabilmesini sağlar.

Resident key'lere, non-resident key'lere ve farklı CTAP sürümlerine göz attıktan sonra, şimdi Güvenen Taraf tarafını ve dolayısıyla WebAuthn sunucu tarafını daha derinlemesine analiz ediyoruz.

WebAuthn'ın esnekliği (ama aynı zamanda karmaşıklığı da) büyük ölçüde sunucu ayarlarına, özellikle de authenticatorSelection nesnesine atfedilir. Bu nesne, istemciye iş için doğru doğrulayıcıyı seçmesinde rehberlik eder.

{
    "rp": {
        "name": "corbado.com",
        "id": "corbado.com"
    },
    "user": {
        "id": "dGVzdefEyMjE",
        "name": "test-username",
        "displayName": "test-username"
    },
    "challenge": "mhanjsapJjCNaN_Ttasdfk1C0DymR-V_w_0UVOPsdfdfJG2ON_FK5-ODtqp33443tgqHzuuDjv-NUUmMAE4hg",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "timeout": 60000,
    "excludeCredentials": [],
    "authenticatorSelection": {
        "authenticatorAttachment": "platform",
        "residentKey": "preferred",
        "requireResidentKey": false,
        "userVerification": "preferred"
    },
    "attestation": "none",
    "extensions": {
        "credProps": true
    }
}

Bu sunucu seçeneği, doğrulayıcının istemci cihazına nasıl eklendiğini belirtir. Doğrulayıcının istemciyle nasıl iletişim kurduğuna dair bilgiler sağlar:

Olası Değerler

• Platform: Bu, doğrulayıcının istemcinin platformuna bağlı olduğunu ve dolayısıyla çıkarılamaz olduğunu gösterir.
• Cross-platform: Bu, doğrulayıcının istemcinin platformuna bağlı olmadığını ve birden fazla cihazda kullanılabileceğini gösterir.

Kullanım Alanları ve Örnekler

• Platform: Örnekler arasında bir dizüstü bilgisayara yerleşik bir parmak izi okuyucu veya bir telefondaki yüz tanıma sistemi, örneğin Face ID, Touch ID veya Windows Hello bulunur.
• Cross-platform: Örnekler arasında USB güvenlik anahtarları (örneğin, YubiKey'ler), Bluetooth cihazları veya NFC kartları bulunur.

WebAuthn Seviye 1 belirtiminde, bu sunucu seçeneği requireResidentKey olarak adlandırılıyordu ve Boolean değerleri olan true (doğrulayıcı bir resident key oluşturmalıdır) veya false (doğrulayıcı bir non-resident key oluşturmalıdır) değerlerini alabiliyordu. WebAuthn Seviye 2 bu sunucu seçeneğini yeni residentKey sunucu seçeneği ile değiştirdi:

Olası Değerler

• Required (Gerekli): Doğrulayıcı bir resident key oluşturmalıdır (mümkün değilse işlem başarısız olmalıdır).
• Preferred (Tercih Edilen): Doğrulayıcı bir resident key oluşturmaya çalışmalıdır (mümkün değilse bir non-resident key oluşturmalıdır).
• Discouraged (Önerilmeyen): Doğrulayıcı bir non-resident key oluşturmalıdır (mümkün değilse işlem başarısız olmalıdır).

Kullanım Alanları ve Örnekler

• Required: Kullanıcı adısız istenen veya kullanıcıların yalnızca daha önce kaydedilmiş cihazlardan kimlik doğrulaması yapması gereken senaryolar için idealdir (kullanıcının kimlik bilgisini belirli bir cihaza bağlayarak ekstra bir güvenlik katmanı ekleyerek).
• Preferred: Web hizmetinin mümkünse en iyi oturum açma kullanıcı deneyimini (resident key'ler aracılığıyla) sunmak istediği, ancak resident key'lerin mümkün olmadığı durumlarda non-resident key'leri de desteklemek istediği senaryolar için uygundur.
• Discouraged: Bir hizmet, passkey ile kimlik doğrulama sunmak ve aynı zamanda kullanıcıların depolama kapasitesi olmayanlar da dahil olmak üzere herhangi bir doğrulayıcıyı, kimlik bilgisini belirli bir cihaza bağlamadan kullanabilmelerini sağlamak istiyor.

Kullanıcı doğrulaması, doğrulayıcıyla etkileşime giren kişinin meşru sahip olduğundan emin olma sürecini ifade eder; genellikle PIN girme, parmak izi sağlama veya yüz tanıma kullanma gibi belirli bir kimlik doğrulama hareketi gerektirir.

Bazen kullanıcı varlığı (UP - user presence), kullanıcı doğrulaması ile benzer şekilde bahsedilir veya kullanılır ancak bazı farklılıkları vardır. Kullanıcı varlığı yalnızca birinin -herhangi birinin- fiziksel olarak mevcut olduğunu ve cihazla etkileşimde bulunduğunu doğrular. O kişinin kimliğini doğrulamaz. Başka bir kimlik kontrolü olmaksızın bir güvenlik anahtarına basit bir dokunuş, kullanıcı varlığı için yeterli olabilir. Passkey'ler / WebAuthn için, kullanıcının her zaman mevcut olması gerekir.

Olası Değerler

• Required (Gerekli): İşlemde kullanıcı doğrulaması olmalıdır.
• Preferred (Tercih Edilen): İşlemde mümkünse kullanıcı doğrulaması olmalıdır, ancak onsuz da devam edebilir.
• Discouraged (Önerilmeyen): İşlemde kullanıcı doğrulaması olmamalıdır.

Kullanım Alanları ve Örnekler

• Required: Bankacılık veya sağlık gibi yüksek güvenlikli uygulamalar için idealdir, burada kullanıcının kimliğini (örneğin, bir parmak izi veya PIN aracılığıyla) doğrulamak çok önemlidir.
• Preferred: Ekstra güvenliğin bir bonus olduğu ancak kesinlikle gerekli olmadığı genel uygulamalar için kullanışlıdır.
• Discouraged: Düşük riskli işlemler veya kullanıcı doğrulamasının bir rahatsızlık olabileceği senaryolar için uygundur.

Kalıp

• Doğrulayıcı eklentisi: platform
• Resident key: required
• Kullanıcı doğrulaması: required

Örnek: Bir kurumsal uygulama, çalışanların şirket tarafından verilen dizüstü bilgisayarlarında yerleşik parmak izi okuyucularını kullanarak şifre olmadan giriş yapmalarını ister. Kimlik bilgisi cihazda saklanır ve kullanıcının her seferinde bir parmak izi ile doğrulaması gerekir.

Kalıp

• Doğrulayıcı eklentisi: cross-platform
• Resident key: required
• Kullanıcı doğrulaması: required

Örnek: Bir kullanıcı, çevrimiçi bankacılık için bir güvenlik anahtarı (örneğin, YubiKey) kaydeder. Bu anahtarı, kullanıcı adı girmesine gerek kalmadan güvenlik anahtarını (örneğin, YubiKey) sağlayarak herhangi bir cihazda kimlik doğrulamak için kullanabilir.

Birçok donanım tabanlı güvenlik anahtarının (örneğin, YubiKey'ler) doğasında depolama kısıtlamaları vardır. Bu sınırlama, cihazdaki fiziksel bellek ve üreticinin tasarım considerations bağlıdır.

Örnek: Bir YubiKey yalnızca 20 resident key saklama kapasitesine sahip olabilir. Bu sınıra ulaşıldığında, mevcut olanları silmeden ek resident key'ler eklenemez.

Çözüm:

• Resident Key'lerin Seçici Kullanımı: Her kullanıcı için resident key kullanmak yerine, bunları belirli roller veya senaryolar için düşünün. Örneğin, gelişmiş güvenlik gerektiren yönetici rolleri veya yüksek ayrıcalıklı kullanıcılar için resident key'lere öncelik verin.
• Kullanıcı Eğitimi: Kullanıcıları güvenlik anahtarlarının (örneğin, YubiKey'ler) sınırlamaları hakkında bilgilendirin. Onları sınırsız resident key kullanabilen cihazlara, örneğin dizüstü bilgisayarlara veya akıllı telefonlara geçmeye teşvik edin.

Farklı doğrulayıcılar, resident key isteklerini farklı şekilde işleyebilir. Bazıları açıkça istenmese bile varsayılan olarak bir resident key oluşturabilirken, diğerleri açık talimat gerektirebilir.

Farklı WebAuthn sunucu seçeneklerinin farklı platformlardaki tutarsız davranışı büyük bir sorundur. Örneğin, iOS, iletilen WebAuthn sunucu seçeneklerinden bağımsız olarak her zaman bir resident key oluştururken, Android bir katılım (örneğin, residentKey: preferred veya residentKey: required ile) gerektirir.

Davranışın yanı sıra, sunucu tarafında saklanan verilere dayanarak, saklanan bir kimlik bilgisinin resident key mi yoksa non-resident key mi olduğunu %100 kesinlikle söyleyememeniz daha da kötüdür. Bunun yerine, bazı kontrolleri takip edebilir ve daraltabilirsiniz (aşağıya bakın), ancak yine de kimlik bilgisinin davranışının inancınıza göre olmasını ummanız gerekir.

Bunun arkasındaki neden, kimlik bilgisinin türü (resident key veya non-resident key) hakkındaki bilgilerin kimlik bilgisi özellikleri uzantısında (clientExtensionResults.credProps.rk, true veya false olan) saklanması için bir WebAuthn önerisi olmasıdır. Ancak, bu bilginin RP'ye sağlanması garanti edilmez, çünkü tüm WebAuthn uzantıları isteğe bağlıdır, örneğin iOS bunu göndermez (bu yüzden resident key mi yoksa non-resident key mi olduğunu bilemezsiniz).

Araştırmamız sırasında, oluşturulan kimlik bilgileri hakkında daha fazla ayrıntı sağlayan iki WebAuthn demo sayfasıyla farklı platformlarda ve doğrulayıcılarda (Windows 10, Windows 11, Android 7, Android 13, iOS17, macOS Ventura, YubiKey) davranışı test etmeye çalıştık: https://webauthn.io ve https://webauthntest.identitystandards.io/. İkincisi, eski requireResidentKey özelliği (WebAuthn Seviye 1) ile çalışma ve hatta onu residentKey özelliği (WebAuthn Seviye 2) ile birleştirme imkanı sunar. Ancak, sonuçlar güvenilir değildi (örneğin, iOS için non-resident key belirtti ama açıkça koşullu arayüz çalışıyordu).

Bulduğumuz en güvenilir kontrol şeması şudur:

1. "residentKey" özelliği için WebAuthn sunucu ayarlarınızın ne olduğunu kontrol edin
   1. Eğer "residentKey: required" ve bir kimlik bilgisi başarıyla oluşturulduysa -> bu bir resident key'dir
   2. Eğer "residentKey: preferred" veya "residentKey: discouraged" ise, bir sonraki kontrole geçin
2. credProps.rk uzantısı destekleniyor mu ve sunucudaki kimlik bilgisinde saklanıyor mu?
   1. Eğer credProps.rk = true ise, kimlik bilgisi bir resident key'dir
   2. Eğer credProps.rk = false ise, kimlik bilgisi bir non-resident key'dir
   3. Eğer credProps boşsa, kimlik bilgisinin türü bilinmemektedir

gördüğünüz gibi, bu daraltmaya yardımcı olur, ancak yine de bilinmeyen seçeneği kalır ve anahtar türünü %100 kesinlikle belirleyemezsiniz.

Bu aynı zamanda SUSE'den William Brown'ın harika makalesindeki bulgularıyla da uyumludur; bu makalede Güvenen Taraflar tarafından resident key'lerin zorunlu kılınması durumunda güvenlik anahtarlarının (örneğin, YubiKey'ler) nasıl işe yaramaz hale gelebileceğini özetlemektedir (tablosunu genişlettik):

Tabloda, farklı WebAuthn sunucu resident key seçenekleri için bir resident key oluşturulup oluşturulmadığını (true), bir non-resident key oluşturulup oluşturulmadığını (false) veya başka bir şey olup olmadığını görüyorsunuz.

Çözüm:

• Kapsamlı Test: Dağıtımdan önce, WebAuthn uygulamanızı popüler doğrulayıcıların bir yelpazesinde test ederek davranışlarını anlayın.
• Açık Sunucu Ayarları: WebAuthn sunucunuzu kurarken gereksinimlerinizde açık olun. Yalnızca passkey'leriniz olmasını istiyorsanız, residentKey seçeneğini required olarak ayarlayın (not: bu, sınırlı resident key kapasitesine sahip doğrulayıcılarla başka zorluklara yol açabilir, yukarıya bakın).

Bir kullanıcı güvenlik anahtarındaki (örneğin, YubiKey) depolama sınırına ulaşırsa, hatalarla karşılaşabilir veya yeni kimlik bilgileri kaydedemeyebilir. Bu, kafa karışıklığına ve hayal kırıklığına yol açabilir.

Çözüm:

• Zarif Hata İşleme: Kullanıcıya güvenlik anahtarının (örneğin, YubiKey) dolduğunu bildiren ve sorunu nasıl çözecekleri konusunda rehberlik sağlayan açık hata mesajları uygulayın.
• Rehberli İş Akışları: Kullanıcıların resident key'lerini nasıl yönetebilecekleri konusunda adım adım kılavuzlar veya eğitimler sunarak, sorunları bağımsız olarak çözebilmelerini sağlayın.

9. Geliştiriciler ve Ürün Yöneticileri için En İyi Uygulamalar

Yukarıda gördüğünüz gibi, seçtiğiniz WebAuthn sunucu ayarları, kimlik doğrulama sürecinizin kullanıcı deneyimini ve güvenliğini önemli ölçüde etkileyebilir. Bilinçli kararlar vermek için bu ayarların inceliklerini anlamak esastır.

Resident ve Non-resident Key'ler: Kullanıcılarınızın çoğunluğu hizmetinize öncelikle akıllı telefonlar veya dizüstü bilgisayarlar gibi kişisel cihazlardan erişiyorsa, resident key'ler uygun bir seçimdir. Resident key'ler cihazın kendisinde saklanır ve aynı cihazı sık kullanan kullanıcılar için sorunsuz bir kimlik doğrulama deneyimi sunar. Ancak, non-resident key olan güvenlik anahtarları (örneğin, YubiKey'ler) kullanan kullanıcılar için bu daha uygun olabilir.

Kullanıcı Doğrulama (UV) Ayarları: Ulaşmak istediğiniz güvenlik düzeyine bağlı olarak, kullanıcı doğrulama sürecinin ne kadar sıkı olacağına karar verebilirsiniz. Yüksek güvenlik hedefliyorsanız, bir PIN, parmak izi veya yüz tanıma gerektirmek (userVerification: preferred veya userVerification: required) tavsiye edilir.

Attestation ve Güvenilirlik: Attestation, doğrulayıcının kökenini ve bütünlüğünü doğrulamanıza olanak tanır. Tüm doğrulayıcılara mı yoksa yalnızca belirli üreticilerden gelenlere mi güveneceğinize karar verin. Bu, hassas verilerle uğraşıyorsanız ve yalnızca yüksek kaliteli, güvenilir doğrulayıcıların kullanılmasını sağlamak istiyorsanız çok önemli olabilir.

Yedek Mekanizmalar: Her zaman bir yedek mekanizma bulundurun. Bir kullanıcı doğrulayıcısını kaybederse veya arızalanırsa, hesabına erişmek için alternatif bir yolları olmalıdır. Bu, yedek kodlar, SMS doğrulaması, e-posta sihirli bağlantıları veya diğer çok faktörlü kimlik doğrulama yöntemleri aracılığıyla olabilir.

Sürekli Eğitim: Passkey'ler ve WebAuthn dünyası sürekli gelişmektedir. En son gelişmeler, güvenlik açıkları ve yamalarla güncel kalın. Geliştirme ekibinizi passkey'ler ve WebAuthn ile ilgili atölye çalışmalarına, webinarlara ve konferanslara katılmaya teşvik edin.

Kullanıcı Kaydı ve Eğitimi: Passkey ile kimlik doğrulamayı tanıtırken, kullanıcılarınızın faydalarını ve nasıl çalıştığını anladığından emin olun. Kayıt işlemi sırasında net talimatlar sunun ve kullanıcıların passkey'leri kurmasına ve kullanmasına yardımcı olacak kaynaklar (SSS'ler veya video eğitimleri gibi) sağlayın.

Bu en iyi uygulamalara bağlı kalarak, geliştiriciler ve ürün yöneticileri, hem güvenliği hem de kullanıcı deneyimini dengeleyerek passkey ile kimlik doğrulamayı etkili bir şekilde uygulayabilirler.

Web sitenizde veya uygulamanızda genel kullanıma yönelik passkey'leri uygulamak istiyorsanız ve güvenlik anahtarlarını (örneğin, YubiKey'ler) desteklemeniz gerekmiyorsa, çünkü kullanıcılarınızın çoğu sadece akıllı telefonlarını veya dizüstü bilgisayarlarını kullanacaksa, aşağıdaki ayarları öneririz.

• authenticator: platform
• residentKey: required
• userVerification: required

Faydaları:

• Oluşturulan tüm anahtarlar resident key olduğundan, kurulum Koşullu Arayüz için olanak tanır ve kullanıcılarınızın bir kullanıcı adı hatırlamak zorunda kalmamasıyla giriş işlemini daha da sorunsuz hale getirir.
• Apple, Google ve Microsoft'un tüm modern cihazları desteklenir ve passkey kullanır.

WebAuthn'ın sunucu ayarları karmaşık olmakla birlikte, kimlik doğrulama için sağlam ve esnek bir çerçeve sunar. Bu ayarlarda uzmanlaşmak çok önemlidir, çünkü bu sadece yeni bir standart uygulamakla ilgili değil; kullanıcı kimlik doğrulamasının güvenliğini ve verimliliğini temelden iyileştirmekle ilgilidir.

Özünde, WebAuthn'ın sunucu ayarlarını anlamak, daha güvenli, verimli ve ileriye dönük uygulamalar oluşturmaya yönelik bir yatırımdır. Dijital dünya geliştikçe, bu tür teknolojilerde bilgili olmak vazgeçilmez olacaktır. Güncel kalmak için passkeys topluluğumuza katılın veya aşağıdaki bültenimize abone olun.