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

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ğlı taraf kimliğinde (RP kimliği) belirtilir. example.com alanı için oluşturulan geçiş anahtarlarında 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ı engellerken şu konularda sorunlara yol açar:

• Birden fazla alanı olan siteler: Kullanıcılar, aynı şirket tarafından yönetilen farklı ülkeye özgü 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ın genellikle kendi alanları yoktur. Bu nedenle, kimlik bilgisi yönetimi zor olabilir.

Kimlik federasyonuna dayalı geçici çözümler ve iFrame'lere dayalı çözümler olsa da bunlar bazı durumlarda kullanışlı değildir. İlgili kaynak istekleri teklifi bir çözüm sunar.

Çözüm

İlgili Kaynak İstekleri ile bir web sitesi, 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ı sunmalıdır.

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

Bu sitelerden herhangi biri bir sonraki geçiş anahtarı oluşturma (navigator.credentials.create) veya kimlik doğrulama (navigator.credentials.get) isteğinde bulunduğunda ve bu istekte RP kimliği olarak example.com kullanıldığında tarayıcı, istekte bulunan kaynakla eşleşmeyen bir RP kimliği olduğunu fark eder. Tarayıcı, İlgili Kaynak İstekleri'ni destekliyorsa önce https://{RP ID}/.well-known/webauthn konumunda bir webauthn dosyası arar. Dosya varsa tarayıcı, isteği yapan kaynağın allowlist üzerinde olup olmadığını kontrol eder. Evetse geçiş anahtarı oluşturma veya kimlik doğrulama adımlarına geçilir.

Tarayıcı, İlgili Kaynak İstekleri'ni desteklemiyorsa SecurityError hatası verir.

Tarayıcı desteği

İlgili kaynak istekleri Chrome ve Safari'de desteklenir. Ocak 2026 itibarıyla Firefox, bu özelliği hâlâ değerlendirmektedir. Bu sorunun durumunu Mozilla standartları konum sorunu sayfasından takip edebilirsiniz.

İlgili Kaynak İsteklerini Ayarlama

Aşağıdaki demoda https://ror-1.glitch.me ve https://ror-2.glitch.me olmak üzere iki site kullanılmaktadır. Kullanıcıların her iki sitede de aynı geçiş anahtarıyla oturum açabilmesini sağlamak için ror-2.glitch.me'nın ror-1.glitch.me'yi RP kimliği olarak 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, geçiş anahtarı oluşturulurken veya geçiş anahtarıyla kimlik doğrulama yapılırken hem ror-1 hem de ror-2, RP kimliği olarak ror-1.glitch.me kullanır. Ayrıca bu sitelerde ortak 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 da ror-2 üzerinde başarıyla geçiş anahtarı oluşturabilir ve bu anahtarla kimliğinizi doğrulayabilirsiniz.
• ror-1 veya ror-2 üzerinde geçiş anahtarı oluşturduktan sonra hem ror-1 hem de ror-2 üzerinde bu geçiş anahtarıyla kimliğinizi doğrulayabilirsiniz. ror-2, RP kimliği olarak ror-1'yi belirttiğinden bu sitelerden herhangi birinde geçiş anahtarı oluşturma veya kimlik doğrulama isteğinde bulunmak, ror-1'de istekte bulunmakla aynıdır. Bir isteği kaynağa bağlayan tek şey RP kimliğidir.
• ror-1 veya ror-2 üzerinde oluşturduğunuz geçiş anahtarları, Chrome tarafından hem ror-1 hem de ror-2 üzerinde otomatik olarak doldurulabilir.
• Bu sitelerin herhangi birinde oluşturulan kimlik bilgilerinin RP kimliği ror-1 olur.

Kodu göster:

• ror-1 kod tabanında oluşturulan /.well-known/webauthn dosyasına bakın.
• ror-2 kod tabanında RP_ID_ROR oluşumlarını inceleyin.

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

Kullanıcılarınızın site-1 ve site-2 sitelerinde 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ı ayarlayın

Öncelikle, site-1.com öğesini site-2.com öğesinin RP kimliği olarak kullanmasına izin verecek şekilde yapılandırın. Bunu yapmak 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 dizeden oluşan bir dizi olan origins adlı bir anahtar içermelidir.

Önemli sınırlama: En fazla 5 etiket

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

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

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

Ö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 önceden ayarlayan express res.json kullanıyoruz.

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

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

• Kimlik bilgileri oluşturulduktan sonra:
  • site-1.com kimliğini, navigator.credentials.create ön uç çağrısına iletilen ve genellikle sunucu tarafında oluşturulan kimlik bilgisi oluşturma işleminde RP kimliği olarak ayarlayın.options
  • Kimliği veritabanınıza kaydetmeden önce kimlik bilgisi doğrulamaları yaptığınız için beklenen RP kimliği olarak site-1.com değerini ayarlayın.
• Kimlik doğrulama işleminden sonra:
  • Kimlik doğrulama options'da site-1.com'yı RP kimliği olarak ayarlayın. Bu kimlik doğrulama, navigator.credentials.get ön uç çağrısına iletilir ve genellikle sunucu tarafında oluşturulur.
  • Kullanıcının kimliğini doğrulamadan önce kimlik bilgisi doğrulamaları yaptığınız için sunucuda doğrulanacak beklenen RP kimliği olarak site-1.com değerini ayarlayın.

Sorun giderme

Dikkat edilmesi gereken diğer noktalar

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

İlgili kaynak istekleri, kullanıcılarınızın birden fazla sitede geçiş anahtarı kullanmasına olanak tanır. Kullanıcılarınızın web sitesi ve mobil uygulama arasında geçiş anahtarını yeniden kullanmasına izin vermek için aşağıdaki teknikleri kullanın:

• Chrome'da: Digital Asset Links. Daha fazla bilgi için Add support for Digital Asset Links (Dijital Öğeler Bağlantıları için destek ekleme) başlıklı makaleyi inceleyin.
• Safari'de: İlişkilendirilmiş alan adları.

Şifreleri siteler arasında paylaşma

İlgili Kaynak İstekleri, kullanıcılarınızın siteler arasında geçiş anahtarı kullanmasına olanak tanır. Siteler arasında şifre paylaşma çözümleri, şifre yöneticileri arasında farklılık gösterir. Google Şifre Yöneticisi için Digital Asset Links 'i kullanın. Safari'nin farklı bir sistemi vardır.

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

Bu, site geliştirici 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ı biraz zaman alacaktır. Geçici bir çözüm olarak hem mevcut web sitesi hem de orijinal kayıt sitesi gösterilebilir.