Bu sayfa, Cloud Translation API ile çevrilmiştir.

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

Maud Nalpas

İlgili Kaynak İstekleri'nin çözdüğü sorun

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ğımsız 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.

Kısıtlanmış taraf kimlikleri ise geçiş anahtarlarının her yerde kimlik doğrulaması yapmak ş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ı alan adları (örneğin acme.com ve acmerewards.com) tıklayın.
Mobil uygulamalar: Mobil uygulamaların genellikle kendi alanı yoktur. Bu durum, zorlayıcı bir hale geldi.

Bazı çözümler, kimlik federasyonuna dayalıdır. ancak bazı durumlarda elverişsizdir. İlgili Kaynak İstekleri bir çözüm sunar.

Çözüm

Entegre İlgili Kaynak İstekleri Bir web sitesi, RP kimliğini kullanmasına izin verilen kaynakları belirtebilir.

Bu sayede, kullanıcılar aynı geçiş anahtarını birden fazla sitede tekrar 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 şunu yapmak istiyorsa: ek kaynakların bunu Kısıtlanmış Taraf Kimliği olarak kullanmasına izin veriyorsa aşağıdaki gibi sunulmalıdır: dosya: https://example.com/.well-known/webauthn:

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

Bu sitelerden herhangi biri bir dahaki sefere geçiş anahtarı oluşturma çağrısı yaptığında (navigator.credentials.create) veya kimlik doğrulama (navigator.credentials.get) bir kısıtlanmış taraf kimliği olarak example.com kullanan bir Kısıtlanmış Taraf Kimliği istekte bulunan kaynakla eşleşmiyor. Tarayıcı, Related Origin'i destekliyorsa istiyorsa, öncelikle bir https://{RP ID}/.well-known/webauthn konumunda webauthn dosyası var. Dosya mevcutsa tarayıcı, isteği yapan kaynağın dosyası olarak kaydedebilirsiniz. Bu durumda, geçiş anahtarı oluşturma veya kimlik doğrulama adımlarına geçilir. Tarayıcı, İlgili Kaynak İstekleri'ni desteklemiyorsa bir SecurityError atar.

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: Pozisyon bekleniyor.

İlgili Kaynak İstekleri'ni ayarlama

Aşağıdaki demoda https://ror-1.glitch.me ve https://ror-2.glitch.me olmak üzere iki site örneği kullanılmıştır.
Kullanıcıların her iki sitede de aynı geçiş anahtarıyla oturum açmasını sağlamak için İlgili Kaynak İstekleri'ni kullanır. Böylece ror-2.glitch.me, ror-1.glitch.me adresini RP kimliği olarak kullanabilir.

Demo

https://ror-2.glitch.me, ror-1.glitch.me'yi RP kimliği olarak kullanmak için İlgili Kaynak İsteklerini 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 siteler genelinde paylaşılan bir geçiş anahtarı veritabanı uyguladık.

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

Kısıtlanmış Taraf kimliği ror-1 olmasına rağmen (ror-2 değil) ror-2 üzerinde başarıyla geçiş anahtarı oluşturabilir ve bu geçiş anahtarını kullanarak 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. Kısıtlanmış taraf kimliği, isteği bir kaynağa bağlayan tek şeydir.
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 sitelerin herhangi birinde oluşturulan kimlik bilgisinin RP kimliği ror-1 olur.

Chrome her iki sitede de otomatik olarak doldurulur. — İlgili Kaynak İstekleri sayesinde kullanıcılar ror-1 ve ror-2'de aynı geçiş anahtarı kimlik bilgisini kullanabilir. Chrome ayrıca kimlik bilgilerini otomatik olarak doldurur.

Kodu inceleyin:

ror-1 kod tabanında oluşturulan ./well-known/webauthn dosyasını inceleyin.
ror-2 kod tabanında RP_ID_ROR oluşumunu görün.

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

Kullanıcılarınızın aynı geçiş anahtarıyla site-1 ve site-2, bu hesaplar arasında paylaşılan bir hesap veritabanını uygular iki site var.

2. Adım: .well-known/webauthn JSON dosyanızı site-1 konumunda oluşturun

Öncelikle site-1.com uygulamasını, site-2.com tarafından bir Kısıtlanmış Taraf Kimliği. 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 öğesinin eTLD + 1 etiketi example-rewards. Chrome'da maksimum etiket sayısı 5'tir.

3. Adım: .well-known/webauthn JSON dosyanızı site-1 içinde sunun

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

Örneğin, ekspres modda:

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

Burada, halihazırdares.json doğru content-type ('application/json');

4. Adım: Site-2'de istediğiniz kısıtlanmış taraf kimliğini belirtin

site-2 kod tabanınızda, gereken her yerde site-1.com kimliğini kısıtlanmış taraf kimliği olarak ayarlayın:

Kimlik bilgisi oluşturulduktan sonra:
- Kimlik bilgisi oluşturma sırasında site-1.com kimliğini Kısıtlanmış Taraf Kimliği olarak ayarlayın options ile navigator.credentials.create ön uç çağrısıyla yapılır ve genellikle sunucu tarafında oluşturulur.
- Kimlik bilgisini çalıştırırken site-1.com öğesini beklenen kısıtlanmış taraf kimliği olarak ayarlayın. doğrulamaları gerekir.
Kimlik doğrulama sonrasında:
- 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.
- site-1.com öğesini şurada doğrulanacak beklenen RP kimliği olarak ayarlayın: sunucu.

Sorun giderme

Chrome'daki hata mesajı pop-up'ı. — Kimlik bilgileri oluşturulduktan sonra Chrome'da hata mesajı görüntüleniyor. ".well-known/webauthn" dosyanız "https://{RP ID}/.well-known/webauthn" adresinde bulunamazsa 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 geçiş anahtarını birden fazla cihazda tekrar kullanmasına olanak tanır. kullanın. Kullanıcılarınızın geçiş anahtarını bir web sitesinde ve mobil uygulamada yeniden kullanmasına izin vermek için: şu teknikleri kullanın:

Chrome'da: Dijital Varlık Bağlantılar başlıklı makaleyi inceleyin. Daha fazla bilgiyi şuradan edinebilirsiniz: Dijital varlık bağlantıları için destek ekleyin.
Safari'de: İlişkili alanlar.

Şifreleri siteler arasında paylaşma

İlgili Kaynak İstekleri, kullanıcılarınızın siteler arasında geçiş anahtarını tekrar kullanmasına olanak tanır. Siteler arasında şifre paylaşımına ilişkin çö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 sizin kapsamınızın dışında kalır ancak ne kadar uzun sürece teriminde, RP Kimliği, kullanıcı aracısında kullanıcının görebildiği bir kavram olmamalıdır. kimlik bilgisi yöneticisi olarak oturum açın. Bunun yerine kullanıcı aracıları ve kimlik bilgileri Yöneticiler, kullanıcılara kimlik bilgilerinin nerede kullanıldığını göstermelidir. Bu değişiklik zaman alır. Geçici bir çözüm, hem mevcut web sitesi ve orijinal kayıt sitesi.