İ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, güvenilir taraf kimliğinde (RP kimliği) belirtilir. example.com alanı için oluşturulan geçiş anahtarlarında bu kimlik www.example.com veya example.com olabilir.

RP kimlikleri, şifre 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ı içeren siteler: Kullanıcılar, aynı şirket tarafından yönetilen farklı ülkeye özgü alan adlarında (ö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

İ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ı yayınlamanı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 bir sonraki sefer RP kimliği olarak example.com'yi kullanan bir geçiş anahtarı oluşturma (navigator.credentials.create) veya kimlik doğrulama (navigator.credentials.get) çağrısı yaptığında tarayıcı, istek gönderen 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 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 geçilir. 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şturduktan veya bu anahtarla kimlik doğrulamasından sonra RP kimliği olarak ror-1.glitch.me'i 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-2 değil ror-1 olsa bile ror-2'te geçiş anahtarı oluşturabilir ve bu anahtarla kimlik doğrulaması yapabilirsiniz.
  • ror-1 veya ror-2'te geçiş anahtarı oluşturduktan sonra hem ror-1 hem de ror-2'te kimliğinizi doğrulayabilirsiniz. ror-2, ror-1'yi RP kimliği olarak belirttiği için bu sitelerden herhangi birinde geçiş anahtarı oluşturma veya kimlik doğrulama isteği göndermek, ror-1'de istek göndermekle aynıdır. RP kimliği, bir isteği bir kaynağa bağlayan tek şeydir.
  • ror-1 veya ror-2'te oluşturduğunuz geçiş anahtarı, Chrome tarafından hem ror-1 hem de ror-2'te 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: Ortak hesap veritabanı uygulayın

Kullanıcılarınızın site-1 ve site-2'te aynı geçiş anahtarıyla oturum açabilmesini istiyorsanız bu iki sitede 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. 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 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
    • Kimlik bilgisi doğrulama işlemlerini veritabanınıza kaydetmeden önce 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'da hata mesajı pop-up'ı.
Kimlik bilgisi oluşturulduktan sonra Chrome'da hata mesajı. ".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 bulunabilir ancak kimlik bilgisi oluşturmaya çalıştığınız kaynağı listelemiyorsa bu hata meydana gelir.

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 bir 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'nin farklı bir sistemi vardır.

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 olarak hem mevcut web sitesini hem de orijinal kayıt sitesini gösterebilirsiniz.