İlgili kaynak istekleri ile sitelerinizde geçiş anahtarının yeniden kullanılmasına izin verin

Maud Nalpas
Maud Nalpas

Geçiş anahtarları belirli bir web sitesine bağlıdır ve yalnızca oluşturuldukları web sitesinde oturum açmak için kullanılabilir.

Bu, bağımlı taraf kimliğinde (RP kimliği) belirtilir. Bu kimlik, example.com alanı için oluşturulan geçiş anahtarları için www.example.com veya example.com olabilir.

RP kimlikleri, geçiş anahtarlarının her yerde kimlik doğrulama için tek bir kimlik bilgisi olarak kullanılmasını engellese de aşağıdakiler için sorun oluşturur:

  • Birden fazla alan adına sahip siteler: Kullanıcılar, aynı şirket tarafından yönetilen ülkeye özgü farklı alanlarda (ör. example.com ve example.co.uk) oturum açmak için aynı geçiş anahtarını kullanamaz.
  • Markalı alanlar: Kullanıcılar, tek bir marka tarafından kullanılan farklı alanlarda (örneğin, acme.com ve acmerewards.com) aynı kimlik bilgilerini kullanamaz.
  • Mobil uygulamalar: Mobil uygulamalar genellikle kendi alanlarına sahip olmadığından kimlik bilgisi yönetimini zorlaştırır.

Kimlik federasyonuna dayalı ve iframe'lere dayalı bazı geçici çözümler olsa da bunlar bazı durumlarda uygun değildir. İlgili Kaynak İstekleri bir çözüm sunar.

Çözüm

Web sitesi, İlgili Kaynak İstekleri ile kendi RP kimliğini kullanmasına izin verilen kaynakları belirtebilir.

Bu sayede kullanıcılar, işlettiğiniz birden fazla sitede aynı geçiş anahtarını yeniden kullanabilir.

İlgili Kaynak İstekleri'ni kullanmak için belirli bir URL'de (https://{RP ID}/.well-known/webauthn) özel bir JSON dosyası sunmanız gerekir. example.com, ek kaynakların bunu RP kimliği olarak kullanmasına izin vermek istiyorsa https://example.com/.well-known/webauthn: adresinde aşağıdaki dosyayı yayınlamalıdır.

{
    "origins": [
        "https://example.co.uk",
        "https://example.de",
        "https://example-rewards.com"
    ]
}

Bu sitelerden herhangi biri, RP kimliği olarak example.com kullanan bir sonraki geçiş anahtarı oluşturma (navigator.credentials.create) veya kimlik doğrulama (navigator.credentials.get) çağrısında bulunduğunda tarayıcı, istekte bulunan kaynakla eşleşmeyen bir RP kimliği fark eder. Tarayıcı, İlgili Kaynak İstekleri'ni destekliyorsa önce https://{RP ID}/.well-known/webauthn adresinde bir webauthn dosyası arar. Dosya mevcutsa tarayıcı, isteği yapan kaynağın söz konusu dosyada izin verilenler listesine eklenip eklenmediğini kontrol eder. Bu durumda geçiş anahtarı oluşturma veya kimlik doğrulama adımlarına devam edilir. Tarayıcı, İlgili Kaynak İstekleri'ni desteklemiyorsa SecurityError hatası verir.

Tarayıcı desteği

  • Chrome: Chrome 128 ve sonraki sürümlerde desteklenir.
  • Safari: macOS 15 beta 3 ve iOS 18 beta 3 mobil sürümlerinden itibaren desteklenir.
  • Firefox: Konum bekleniyor.

Aşağıdaki demoda https://ror-1.glitch.me ve https://ror-2.glitch.me adlı iki site örneği kullanılmaktadır.
Kullanıcıların bu iki sitede de aynı geçiş anahtarıyla oturum açabilmesini sağlamak için ror-2.glitch.me'ın RP kimliği olarak ror-1.glitch.me kullanmasına izin vermek üzere İlgili Kaynak İstekleri'ni kullanır.

Demo

https://ror-2.glitch.me, ror-1.glitch.me'yi RP kimliği olarak kullanmak için İlgili Kaynak İstekleri'ni uygular. Bu nedenle, hem ror-1 hem de ror-2, geçiş anahtarı oluştururken veya kimlik doğrulaması yaparken ror-1.glitch.me kimliğini RP kimliği olarak kullanır.
Ayrıca bu sitelerde paylaşılan bir geçiş anahtarı veritabanı da uyguladık.

Aşağıdaki kullanıcı deneyimini gözlemleyin:

  • RP kimliği ror-1 (ror-2 değil) olsa bile ror-2'te geçiş anahtarı oluşturabilir ve bu anahtarla kimlik doğrulaması yapabilirsiniz.
  • ror-1 veya ror-2 cihazlarında geçiş anahtarı oluşturduktan sonra hem ror-1 hem de ror-2 üzerinde geçiş anahtarıyla kimlik doğrulaması yapabilirsiniz. ror-2, RP kimliği olarak ror-1 değerini belirttiği için bu sitelerin herhangi birinden geçiş anahtarı oluşturma veya kimlik doğrulama isteğinde bulunmak, ror-1'de istekte bulunmayla aynıdır. RP kimliği, bir isteği bir kaynağa bağlayan tek öğedir.
  • ror-1 veya ror-2 cihazlarda geçiş anahtarı oluşturduğunuzda hem ror-1 hem de ror-2 cihazlarda Chrome tarafından otomatik olarak doldurulabilir.
  • Bu sitelerden herhangi birinde oluşturulan kimlik bilgilerinin RP kimliği ror-1 olur.
Chrome, her iki sitede de otomatik doldurma yapar.
İlgili Kaynak İstekleri sayesinde kullanıcılar ror-1 ve ror-2'de aynı geçiş anahtarı kimlik bilgisini kullanabilir. Chrome, kimlik bilgilerini de otomatik olarak doldurur.

Kodu göster:

1. Adım: Paylaşılan hesap veritabanını uygulayın

Kullanıcılarınızın site-1 ve site-2 platformlarında aynı geçiş anahtarıyla oturum açabilmesini istiyorsanız bu iki site arasında paylaşılan bir hesap veritabanı uygulayın.

2. adım: site-1'de .well-known/webauthn JSON dosyanızı oluşturun

Öncelikle site-1.com'ü, site-2.com'un RP kimliği olarak kullanmasına izin verecek şekilde yapılandırın. Bunun için webauthn JSON dosyanızı oluşturun:

{
    "origins": [
        "https://site-2.com"
    ]
}

JSON nesnesi, değeri web kaynaklarını içeren bir veya daha fazla dizenin dizisi olan origins adlı bir anahtar içermelidir.

Önemli sınırlama: Maksimum 5 etiket

Bu listenin her öğesi, eTLD + 1 etiketini ayıklamak için işlenir. Örneğin, example.co.uk ve example.de için eTLD + 1 etiketleri example'dir. Ancak example-rewards.com için eTLD + 1 etiketi example-rewards. Chrome'da maksimum etiket sayısı 5'tir.

3. adım: .well-known/webauthn JSON dosyanızı site-1'de yayınlayın

Ardından, JSON dosyanızı site-1.com/.well-known/webauthn altında yayınlayın.

Örneğin, express'te:

app.get("/.well-known/webauthn", (req, res) => {
  const origins = {
    origins: ["https://site-2.com"],
  };
  return res.json(origins);
});

Burada, doğru content-type ('application/json') değerini zaten ayarlayan express res.json kullanıyoruz;

4. adım: site-2'de istediğiniz RP kimliğini belirtin

site-2 kod tabanınızda, gereken her yerde RP kimliği olarak site-1.com değerini ayarlayın:

  • Kimlik bilgisi oluşturulduktan sonra:
    • Kimlik bilgisi oluşturma işleminde RP kimliği olarak site-1.com'ü ayarlayın. Bu kimlik, navigator.credentials.create ön uç çağrısına aktarılır ve genellikle sunucu tarafında oluşturulur.options
    • Veritabanınıza kaydetmeden önce kimlik bilgisi doğrulamalarını çalıştırırken site-1.com değerini beklenen RP kimliği olarak ayarlayın.
  • Kimlik doğrulamasından sonra:
    • site-1.com kimliğini, navigator.credentials.get ön uç çağrısına iletilen ve genellikle sunucu tarafında oluşturulan kimlik doğrulama options'da RP kimliği olarak ayarlayın.
    • Kullanıcının kimliğini doğrulamadan önce kimlik bilgisi doğrulama işlemlerini çalıştırdığınızda site-1.com değerini, sunucuda doğrulanması beklenen RP kimliği olarak ayarlayın.

Sorun giderme

Chrome'daki hata mesajı pop-up'ı.
Kimlik bilgisi oluşturulduktan sonra Chrome'da hata mesajı gösteriliyor. ".well-known/webauthn" dosyanız "https://{RP ID}/.well-known/webauthn" adresinde bulunamazsa bu hata meydana gelir.
Chrome'da hata mesajı pop-up'ı.
Kimlik bilgisi oluşturulduktan sonra Chrome'da hata mesajı. ".well-known/webauthn" dosyanız bulunabiliyor ancak kimlik bilgisi oluşturmaya çalıştığınız kaynak listelenmiyorsa bu hata verilir.

Dikkat edilmesi gereken diğer noktalar

Geçiş anahtarlarını siteler ve mobil uygulamalar arasında paylaşma

İlgili Kaynak İstekleri, kullanıcılarınızın birden fazla sitede geçiş anahtarını yeniden kullanmasına olanak tanır. Kullanıcılarınızın bir geçiş anahtarını web sitesinde ve mobil uygulamada yeniden kullanmasına izin vermek için aşağıdaki teknikleri kullanın:

Şifreleri siteler arasında paylaşma

İlgili Kaynak İstekleri, kullanıcılarınızın siteler arasında geçiş anahtarını yeniden kullanmasına olanak tanır. Siteler arasında şifre paylaşımı için sunulan çözümler, şifre yöneticilerine göre değişiklik gösterir. Google Şifre Yöneticisi için Dijital Öğe Bağlantıları 'nı kullanın. Safari farklı bir sisteme sahip.

Kimlik bilgisi yöneticilerinin ve kullanıcı aracılarının rolü

Bu, site geliştiricisi olarak kapsamınızın dışındadır ancak uzun vadede RP kimliğinin, kullanıcı aracısında veya kullanıcılarınızın kullandığı kimlik bilgisi yöneticisinde kullanıcı tarafından görülebilen bir kavram olmaması gerektiğini unutmayın. Bunun yerine kullanıcı aracıları ve kimlik bilgisi yöneticileri, kullanıcılara kimlik bilgilerinin nerede kullanıldığını göstermelidir. Bu değişikliğin uygulanması zaman alacaktır. Geçici bir çözüm, hem mevcut web sitesini hem de orijinal kayıt sitesini görüntülemektir.