İ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, relying party ID (RP ID) içinde 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 içeren siteler: Kullanıcılar, aynı şirket tarafından yönetilen farklı ülkeye özgü alanlarda (örneğin, 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 vardır ancak bunlar bazı durumlarda kullanışsızdır. İlgili Kaynak İstekleri, bu soruna çö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) çağrısı yaptığında example.com, RP kimliği olarak kullanılır. 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 gönderen 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, özelliği hâlâ değerlendirmektedir. 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 bu 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 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 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 anahtarla kimlik 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 sitelerden herhangi birinde oluşturulan kimlik bilgilerinin RP kimliği ror-1 olur.

Kodu göster:

• ror-1 codebase'de oluşturulan /.well-known/webauthn dosyasına bakın.
• ror-2 kod tabanında RP_ID_ROR oluşumlarını görün.

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

İlk olarak, site-1.com hizmetini site-2.com hizmetinin 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 kaynaklar 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 sunun

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 zaten 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 bilgisi oluşturulduğunda:
  • Kimlik bilgisi oluşturma işleminde site-1.com öğesini RP kimliği olarak ayarlayın. Bu kimlik bilgileri, navigator.credentials.create ön uç çağrısına iletilir ve genellikle sunucu tarafında oluşturulur.options
  • Kimlik bilgilerini veritabanınıza kaydetmeden önce doğrulama işlemlerini gerçekleştirdiğiniz için beklenen RP kimliği olarak site-1.com değerini ayarlayın.
• Kimlik doğrulama işleminden sonra:
  • Kimlik doğrulama options içinde site-1.com değerini RP kimliği olarak ayarlayın. Bu değerler 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 geçiş anahtarını web sitesi ve mobil uygulamada 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 Öğe Bağlantıları için destek ekleme) başlıklı makaleyi inceleyin.
• Safari'de: İlişkilendirilmiş alan adları.

Siteler arasında şifre 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ı zaman alacaktır. Geçici bir çözüm olarak hem mevcut web sitesi hem de orijinal kayıt sitesi gösterilebilir.