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

Maud Nalpas
Maud Nalpas
X GitHub

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ça belirtilir ID (RP ID) (example.com alanı için oluşturulan geçiş anahtarları için 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 adına sahip siteler: Kullanıcılar, aşağıdaki işlemler için aynı geçiş anahtarını kullanamaz. ülkeye özgü farklı alan adlarında oturum açmak (örneğin, example.com ve example.co.uk) aynı şirket tarafından yönetiliyor.
  • 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 teklifi çözmüş olursunuz.

Çö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 İsteklerini kullanmak için belirli URL: https://{RP ID}/.well-known/webauthn. 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ı, İlgili Kaynak'ı 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 devam edilir. Tarayıcı, İlgili Kaynak İstekleri'ni desteklemiyorsa bir SecurityError atar.

Tarayıcı desteği

ziyaret edin.

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 kullanır.

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.
ziyaret edin.
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:

ziyaret edin.

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 1 dizisi olan kaynak adlı anahtarlar içermelidir veya daha fazla dize içerebilir.

Önemli sınırlama: Maksimum 5 etiket

Bu listenin her öğesi, eTLD + 1 etiketini ayıklamak için işlenir. Örneğin, hem example.co.uk hem de example.de eTLD + 1 etiketlerinin ikisi de example. 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:
    • options kimlik doğrulamasında Kısıtlanmış Taraf Kimliği olarak site-1.com değerini ayarlayın navigator.credentials.get ön uç çağrısına iletilenler ve tarafından oluşturulur.
    • site-1.com öğesini şurada doğrulanacak beklenen RP kimliği olarak ayarlayın: sunucu.
ziyaret edin.

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.
ziyaret edin.
'nı inceleyin.
Chrome'daki hata mesajı pop-up'ı.
Kimlik bilgileri oluşturulduktan sonra Chrome'da hata mesajı görüntüleniyor. ".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 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:

Ş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'de farklı bir sistem var.

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.